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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
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Foreword 

This Technical Specification (TS) has been produced by IMS Network Testing (INT). 

The present document is part 2 of a multi-part deUverable covering the IMS NNI Interworking Test Specifications, as 
identified below: 

Part 1 : "Test Purposes for IMS NNI Interworking"; 

Part 2: "Test Descriptions for IMS NNI Interworking"; 

Part 3: "ATS&PIXIT". 
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Scope 



The present document specifies interoperability Test Descriptions (TDs) for IMS NNI interworking for the IP 
Multimedia Call Control Protocol based on Stage 3 Session Initiation Protocol (SIP) and Session Description 
Protocol (SDP) standard, TS 124 229 Release 6 [1]. TDs have been specified on the basis of the Test Purposes (TPs) 
and test suite structure (TSS) presented in [2]. TP fragments presented in the present document as part of TDs are 
defined using the TPLan notation [5]. TDs have been written based on the test specification framework described in 
TS 102 351 [3] and the interoperability testing methodology defined in TS 102 237-1 [4], i.e. interoperability testing 
with a conformance relation. 

The scope of these test descriptions is not to cover all requirements specified in [1]. It has been reduced to cover only 
requirements which relate to basic IMS call functionality for a minimal interworking IMS CN configuration, i.e. based 
on a P-CSCF, S-CSCF, I-CSCF, and HSS. Therefore, assessment of, e.g. IMS roaming, topology hiding, etc. at the NNI 
are not addressed in this test purpose specification. TDs have been only specified for requirements that are observable at 
the interface between two separate minimal IMS CN implementations, i.e. IMS NNI. 

NOTE: Requirements which can only be observed at the interface between UE and IMS CN, i.e. home P-CSCF, 
are explicitly not within the scope of the present document. The latter requirements have been dealt with 
from a UE and conformance perspective in TS 134 229-1 [6]. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 124 229 (V6. 13.0): "Digital cellular telecommunications system (Phase 2+); Universal 

Mobile Telecommunications System (UMTS); Internet Protocol (IP) multimedia call control 
protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); 
Stage 3 (3GPP TS 24.229 version 6.13.0 Release 6)". 

[2] ETSI TS 186 01 1-1: "Technical Committee for IMS Network Testing (INT); IMS NNI 

Interworking Test Specifications; Part 1: Test Purposes for IMS NNI Interworking". 

[3] ETSI TS 102 35 1 : "Methods for Testing and Specification (MTS); Internet Protocol Testing (IPT); 

IPv6 Testing: Methodology and Framework". 



ETSI 



8 ETSI TS 186 011-2 VI. 1.1 (2009-03) 

[4] ETSI TS 102 237-1: "Telecommunications and Internet Protocol Harmonization Over Networks 

(TIPHON) Release 4; Interoperability test methods and approaches; Part 1: Generic approach to 
interoperability testing". 

[5] ETSI ES 202 553: "Methods for Testing and Specification (MTS); TPLan: A notation for 

expressing Test Purposes". 

[6] ETSI TS 134 229-1: "Universal Mobile Telecommunications System (UMTS); Internet Protocol 

(IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session 
Description Protocol (SDP); Part 1: Protocol conformance specification (3GPP TS 34.229-1 
Releasee)". 

[7] ETSI TS 123 228 (V6.15.0): "Digital cellular telecommunications system (Phase 2+); Universal 

Mobile Telecommunications System (UMTS); IP Multimedia Subsystem (IMS); Stage 2 (3GPP 
TS 23.228 version 6.15.0 Release 6)". 

[8] ETSI TS 133 203 (V6. 10.0): "Digital cellular telecommunications system (Phase 2+); Universal 

Mobile Telecommunications System (UMTS); 3G security; Access security for IP -based services 
(3GPP TS 33.203 version 6.10.0 Release 6)". 

[9] ETSI TS 123 060 (V6.15.0): "Digital cellular telecommunications system (Phase 2+); Universal 

Mobile Telecommunications System (UMTS); General Packet Radio Service (GPRS); Service 
description; Stage 2 (3GPP TS 23.060 version 6.15.0 Release 6)". 

[10] ETSI TS 127 060 (V6.0.0): "Digital cellular telecommunications system (Phase 2+); Universal 

Mobile Telecommunications System (UMTS); Packet domain; Mobile Station (MS) supporting 
Packet Switched services (3GPP TS 27.060 version 6.0.0 Release 6)". 

[11] IETF RFC 2617: "HTTP Authentication: Basic and Digest Access Authentication". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI TR 133 978 (V6.6.0): "Universal Mobile Telecommunications System (UMTS); Security 

aspects of early IP Multimedia Subsystem (IMS) (3GPP TR 33.978 version 6.6.0 Release 6)". 

[i.2] ETSI TR 123 981 (V6.4.0): "Universal Mobile Telecommunications System (UMTS); 

Interworking aspects and migration scenarios for IPv4-based IP Multimedia Subsystem (IMS) 
implementations (3GPP TR 23.981 version 6.4.0 Release 6)". 



3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

3GPP 3'^'^ Generation Partnership Project 

AKA Authentication and Key Agreement 

AS (IMS) Application Server 

ASO Application Server Origination 

AST Termination at Application Server 

CF (Test) ConFiguration 

CFW Call Flow 

CN Core Network 

CSCF Call Session Control Function 

DHCP Dynamic Host Configuration Protocol 

DNS Domain Name System 

GPRS General Packet Radio Service 

HSS Home Subscriber Server 

I-CSCF Interrogating CSCF 
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IMS IP Multimedia Subsystem 

lOI Inter Operator Identifier 

IP Internet Protocol 

IPSEC Internet Protocol SECure transmission 

MO Mobile Origination 

MT Mobile Termination 

NNI Network-to-Network Interface 

PCO Point Of Control and Observation 

P-CSCF Proxy CSCF 

PDP Packet Data Protocol 

PO POstamble 

PR PReamble 

PRACK Provisional Response Acknowledgement 

PSTN Public Switched Telephone Network 

SA Security Association 

S-CSCF Serving CSCF 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

SUT System Under Test 

TB Test Body 

TCP Transmission Control Protocol 

TD Test Description 

TISPAN Telecommunications and Internet converged Services and Protocols for Advanced Networking 

TP Test Purpose 

TPLan Test Purpose Notation 

TSS Test Suite Structure 

UC Use Case 

UDP User Data Protocol 

UE User Equipment 

URI Uniform Record Identifier 

VoIP Voice over Internet Protocol 

XML Extensible Markup Language 



4 IMS NNI Interoperability Test Specification 



4.1 



Introduction 



The IMS NNI Interoperability Test descriptions (TDs) defined in the following clauses are derived from the Test 
Purposes (TPs) specified in TS 124 229 [1]. 

4.2 Test Prerequisites 

4.2.1 IP Version 

These test specifications are based on the use of IPv4 for SIP message transport throughout all IMS nodes 

(see TR 123 981 [i.2]). 

4.2.2 IP Bearer Establishment 

4.2.2.1 3GPP 

3GPP bearer establishment procedures imply the creation of a PDP context over GPRS (see TS 123 060 [9] and 
TS 127 060 [10]). 
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4.2.3 Authentication and Security 

4.2.3.1 3GPP 

The current test specification supports standard 3GPP security, namely early IMS (see TR 133 978 [i.l]), full IMS 
(see TS 133 203 [8]) and optionally allows SIP Digest authentication without key agreement and null authentication. 
Non-compliance with full IMS security features defined in TS 133 203 [8] is expected to be a problem mainly at the UE 
side, because of the potential lack of support of the USIM/ISIM interface (especially in 2G-only devices) of the 
potential inability to support IPSec on some UE platforms. For those reasons, early IMS is the default security 
configuration in all test descriptions. Tests may be executed with full IMS security if all required IMS nodes support it. 

4.2.4 Registration and Subscription 
4.2.4.1 SIP Call Flow 

This clause describes the registration call flow under the authentication and security scope described in clause 4.2.3. 

4.2.4.1 .1 Early IMS Registration and Subscription Call Flow 

Early IMS security does not allow SIP requests to be protected using an IPSec security association because it does not 
perform a key agreement procedure. IPSec security associations are not set up between UE and P-CSCF, as they are in 
the full IMS security solution. For early IMS security, the expected registration and subscription sequence is: 



Step 


Direction 


lUlessage 


Comment 




UE 1 IMS 




1 






The UE establishes an IP bearer as required by its 
specific access network (optional). 




2 


^-» 




P-CSCF address discovery using DHCP 
procedures for IPv4 (optional). 




3 


^ 


REGISTER 


The UE sends initial registration for IMS services. 


T3 
0) 

O 
0) 

o 

Q. 


4 


<- 


200 OK 


The IMS responds with 200 OK. 


5 


-^ 


SUBSCRIBE 


The UE subscribes to its registration event 
package. 


6 


^ 


200 OK 


The IMS responds with 200 OK. 


7 


«- 


NOTIFY 


The IMS sends initial NOTIFY for registration event 
package, containing full registration state 
information for the registered public user identity in 
the XML body. 


8 


^ 


200 OK 


The UE responds with 200 OK. 
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4.2.4.1 .2 Full IMS Registration and Subscription Call Flow 

For full IMS security, the expected registration and subscription sequence is: 



Step 


Direction 


IVIessage 


Comment 




UE 1 IIUIS 




1 






The UE establishes an IP bearer as required by its 
specific access network (optional). 




2 


^^ 




P-CSCF address discovery using DHCP 
procedures for IPv4 (optional). 




3 


■^ 


REGISTER 


The UE sends initial registration for IMS services. 


T3 

B 

O 

S 
o 


4 


<- 


401 Unauthorized 


The IMS responds with a valid Digest AKA 
authentication challenge and a list of integrity and 
encryption algorithms supported by the network as 
defined in the IMS AKA procedure 
(see TS 133 203 [8]). 


5 






Upon receipt of 401 Unauthorized, the UE selects 
the first integrity and encryption algorithm 
combination on the list received from the P-CSCF in 
401 Unauthorized which is also supported by the 
UE. If the P-CSCF did not include any 
confidentiality algorithm in 401 Unauthorized then 
the UE shall select the NULL encryption algorithm. 
The UE then proceeds to establish two new pairs of 
IPSEC security associations (SA1 and SA2). 




6 


^ 


REGISTER 


The UE sends another REGISTER with 
authentication credentials over IPSEC security 
association SA1 . 


< 

>, 
J3 

T3 
0) 
O 
0) 

£ 

CL 


7 


^ 


200 OK 


The IMS responds with 200 OK over the same 
IPSEC security association SA1 . 


8 


■^ 


SUBSCRIBE 


The UE subscribes to its registration event package 
over the IPSEC security association SA2. 


(M 
< 

>, 
.Q 
T3 

B 
O 
0) 
O 


9 


4- 


200 OK 


The IMS responds with 200 OK over the IPSEC 
security association SA2. 


10 


^ 


NOTIFY 


The IMS sends initial NOTIFY for registration event 
package, containing full registration state 
information for the registered public user identity in 
the XML body, over the IPSEC security association 
SA2. 


11 


^ 


200 OK 


The UE responds with 200 OK over the IPSEC 
security association SA2. 
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4.2.4.1 .3 SIP Digest Registration and Subscription Call Flow 

For SIP Digest authentication without key agreement and null authentication, the expected registration and subscription 
sequence is: 



Step 


Direction 


Message 


Comment 




UE 1 IMS 




1 






The UE establishes an IP bearer as required by its 
specific access networl< (optional). 




2 


^^ 




P-CSCF address discovery using DHCP 
procedures for IPv4 (optional). 




3 


^ 


REGISTER 


The UE sends initial registration for IMS services. 


T3 

S 
O 
0) 

O 

Q. 

Z) 


4 


^ 


401 Unauthorized 


The IMS responds with a valid HTTP Digest 
authentication challenge as defined in 
TS 123 060 [9]. 


5 


^ 


REGISTER 


The UE sends another REGISTER with 
authentication credentials. 


6 


^ 


200 OK 


The IMS responds with 200 OK. 


7 


^ 


SUBSCRIBE 


The UE subscribes to its registration event 
package. 


8 


^ 


200 OK 


The IMS responds with 200 OK. 


9 


^ 


NOTIFY 


The IMS sends initial NOTIFY for registration event 
package, containing full registration state 
information for the registered public user identity in 
the XML body. 


10 


■^ 


200 OK 


The UE responds with 200 OK. 



4.2.5 Supported Options 

4.2.5.1 Security 

Support for security agreement is optional in case of Full IMS Reg. It shall only be used in case all IMS nodes support 
it. 

4.2.5.2 Signalling Compression 

"No sigcomp" is the default signalling configuration in all test descriptions. Tests may be executed with signalling 
compression if the required nodes support it. 

4.2.5.3 Preconditions 

"No precondition" is the default SDP configuration in all test descriptions. Tests may be executed with SDP 
preconditions if the required nodes support it. 

4.2.5.4 Reliable Provisional Responses 

Reliable provisional responses (lOOrel) including the use of the PRACK method are the default signalling configuration 
in all test descriptions. 

4.2.5.5 Forking 

Not applicable in the current test specification. However, support for forking is a requirement of the IMS specification. 



4.3 



Test Infrastructure 



In these clauses we define the involvement of the various IMS nodes specifically as they pertain to NNI testing. The 
configuration of the nodes is described. Points of control and observation are identified and static test configurations are 
described. The Mw interface is the interface under observation for NNI interoperability testing. 



£75/ 



13 ETSI TS 186 011-2 VI. 1.1 (2009-03) 



4.3.1 Core IMS Nodes 



Because the current testing scope excludes IMS roaming and border control functionality, P-CSCF, S-CSCF, I-CSCF, 
and HSS are considered to be within a "black box" for testing purposes. We refer to this System Under Test (SUT) as 
"the minimal IMS". Interfaces within the IMS are considered internal and not observable for testing purposes. The use 
cases and test descriptions described below may be run with IMS roaming without modifications. Due to the limited 
scope, no test descriptions are available that validate the operation of the Mw interface between the P-CSCF and 
S-CSCF as an NNI interface, i.e. in a roaming configuration. 

4.3.1.1 P-CSCF 

4.3.1.1.1 Relevant Interfaces 

The P-CSCF constitutes the point of entry for UE signalling into the IMS core. The Gm interface between the P-CSCF 
and the UE is used as a Point Of Control and Observation (PCO) for NNI interoperability testing purposes. Although 
considered as internal and not explicitly involved in current NNI test configurations which exclude IMS roaming, it is 
recommended that the Mw interface between the P-CSCF and S-CSCF be exposed/available for troubleshooting 
purposes. 

4.3.1.1.2 Node Configuration 

The P-CSCF should be configured to support the pre-requisites outlined in clause 4.2. 

4.3.1.2 S-CSCF 

4.3.1.2.1 Relevant Interfaces 

The S-CSCF is the core IMS node delivering IMS services to subscribers. The Mw interface between the S-CSCF and 
either I- or S-CSCF in another domain is used as a point of observation against which NNI interoperability tests are 
validated. The Mw interfaces between I- and S-CSCFs within the same network are considered as internal IMS 
interfaces. Although considered as internal and not explicitly involved in current NNI test configurations which exclude 
IMS roaming, it is recommended that the Mw interface between the P-CSCF and S-CSCF be exposed for 
troubleshooting purposes. 

4.3.1 .2.2 Node Configuration 

The S-CSCF should be configured to support the pre-requisites outlined in clause 4.2. When applicable based on the 
specific configuration, the S-CSCF must be provisioned to support required Application Servers (AS) as trusted nodes. 

4.3.1.3 HSS 

4.3.1.3.1 Rel evant I nterf aces 

The HSS constitutes the repository for IMS subscriber information. The Cx interface between the HSS and the S-CSCF 
and/or I-CSCF is considered an internal IMS interface. 

4.3.1.3.2 Node Configuration 

The HSS should be configured within the IMS to interact with CSCFs as required using DIAMETER Cx interfaces. For 
the purpose of this test specification, "ims-a.net" refers to the domain served by "IMS_A" and "ims-b.net" refers to the 
domain served by "IMS_B". Users should be provisioned to match the sample profiles listed in table 1. All public 
identities belong to the same implicitly registered set. 
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Table 1 : HSS sample user profiles for IMS_A 



IMS 
Domain 


Private Identity 


Public Identity 1 
(SIP URI) 


Public Identity 2 
(Tel URI) 


Default 
Public 
Identity 


Filter criteria 


ims-a.net 


user 1 Driv(S>ims-a.net 


sip:user 1 pub@ims-a.net 


na 


1 


na 


ims-a.net 


user 2 Driv(S>ims-a.net 


sip:user_2_pub@ims-a.net 


tel:-H3363334827 
3 


1 


na 




lms-a.net 


user 3 Driv(S>ims-a.net 


sip:user_3_pub@ims-a.net 


tel:-H3363334827 
4 


2 


na 




ims-a.net 


user 4 Driv@ims-a.net 


sip:user_4_pub@ims-a.net 


na 


1 


terminating unregistered/INVI 
IE/ 

SESSION_TERMINATED/ 
as-1.ims-a.net 




ims-a.net 


user 5 Driv(a)ims-a.net 


sip:user_5_pub@ims-a.net 


na 


1 





Table 2: HSS sample user profiles for !MS_B 



IMS 
Domain 


Private Identity 


Public Identity 1 
(SIP URI) 


Public Identity 2 
(Tel URI) 


Default 
Public 
Identity 


Filter criteria 


ims-b.net 


user 1 DrivOims-b.net 


sip:user 1jDub@ims-b.net 


na 


1 




ims-b.net 


user 2 Driv(3)inns-b.net 


sip:user_2 jDub@ims-b.net 


tel:+4474445938 
4 


1 






ims-b.net 


user 3 priv(3)ims-b.net 


sip:user_3 jDub@ims-b.net 


tel:+4474445938 
5 


2 






ims-b.net 


user 4 DrivOims-b.net 


sip:user_4 jDub@ims-b.net 


na 


1 


terminating unregistered/INV 
HE/ 

SESSION_TERMINATED/ 
as-2.ims-b.net 




ims-b.net 


user 5 DrivOims-b.net 


sip:user 5jDub@ims-b.net 


na 


1 





4.3.2 External IMS Nodes 



4.3.2.1 



UE 



4.3.2.1.1 Relevant Interfaces 

The UE is considered to act as a stimulus node in this test specification. The Gm interface between the P-CSCF and the 
UE is used as a Point Of Control and Observation (PCO) for NNI interoperability tests. 

4.3.2.1 .2 Node Configuration 

The UE should be configured to support the pre-requisites outUned in clause 4.2. The test descriptions in the present 
document assume that UEs support reliable provisional responses (lOOrel) including the PRACK method basic call and 
messaging functionality, call hold based on UPDATE as well as re-INVITE method, and message transport via UDP as 
well as TCP. In the case that a UE does not meet one or more of these features, only a selected subset of the test 
descriptions in ths present document should be used for IMS core network interoperability testing, i.e. test descriptions 
which do not contain any pass criteria related to these features. 

4.3.2.2 AS 

4.3.2.2.1 Relevant Interfaces 

The application server (AS) is considered to act as a stimulus node in this test specification. The ISC interface between 
the S-CSCF and the AS is used as a Point Of Control and Observation (PCO) for NNI interoperability tests. 

4.3.2.2.2 Node Configuration 

The AS should be configured to support the pre-requisites outlined in clause 4.2. 
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4.3.3 Supporting IMS Nodes 

4.3.3.1 DNS 

4.3.3.1.1 Relevant Interfaces 

The Domain Name Service (DNS) is considered as a supporting entity in the present document. 

4.3.3.1 .2 Node Configuration 

DNS should be configured for appropriate resource record handling as required to support proper resolution of all SIP 
URIs in Request URIs and Route headers. In addition, DNS must support ENUM functionality in order to resolve Tel 
URIs into SIP URIs. As an example, DNS_B should have an entry to map E.164 number 44744459384 with user 
user 2 priv@ims-b.net . 

4.3.4 Test Configurations 

The following architectural test configurations are referenced in the IMS NNI interoperability TDs in the present 
document. They are intended to give a general rather than a specific view of the required IMS SUT(s) connectivity and 
associated UE(s), AS(s), and DNS(s). 

The following guidelines are used to describe the test configurations: 

• Named based convention defined in TS 123 228 [7], clause 5.5.1. 

• Reuse the following abbreviations: 

SSI: Different network operators performing origination and termination. 

M02: Mobile Origination, home. The "Originating Network" of S-S#l is therefore the home network. 

ASO: Application Server Origination. The" Originating Network" of S-S#l is the home network. 

MT2: Mobile Termination, located in home service area. The "Terminating Network" of S-S#l is the 
home network. 

AST4: Termination at Application Server based on service logic. 

• Exclude PSTN, non-IMS endpoints and IMS roaming since these are out of scope. 

• Further differentiate IMS NNI observation points based on: 

IN: initial request/response for a dialog. 

SU: subsequent requests/responses in a dialog. 

ST: standalone requests/response. 

• And indicate: 

Observable interfaces as a solid line. 
Non-observable interfaces as dashed lines. 
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UE 
A 



Gm 



fl- 



PCO 



IMS A 



P-CSCF 



HSS 



'^ S-CSCF ^ 



l-CSCF 



Mw 




PO 



HSS 



l-CSCF 



V J 



IMSB 



^ S-CSCF 1 f P-CSCF 



J V J 



Precondition: 

Different network operators performing origination and termination (SS1 ), UEA in Home networl< A 

(M02), UE_A registered, neitlner AS norTHIG nor IMS-ALG involved 
Test configuration for: 

Unsuccessful initial requests and responses from UEA 
Example: 

Initial INVITE in IMS VoIP voice call from UEA to non-existing user 

Figure 1 : CF_M02-SS1 
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v^ 


l-CSCF 




PO 


l-CSCF ^ 





































Precondition: 

Different network operators performing origination and termination (SSI ), UEA in Home network A 

(M02), UE_B in Home network B (MT2), both UEs registered, neitfier AS nor THIG nor IMS-ALG 

involved, in SU case dialog initiated between UEA and UEB 
Test configuration for: 

Initial (IN) and Subsequent (SU) requests and responses between UEA and UEB 
Example: 

IN: Initial INVITE in IMS VoIP voice call from UE_A to UE_B 

SU: BYE request, UE_B terminates IMS VoIP call towards UE_B 

Figure 2: CF_l\fl02-SS1-IVIT2 
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Precondition, 

Different netoork operators performing origination and termination (SSI), UE_A in Home ne&vorl< A 

(M02), UE_B in Home networl< B (MT2), only UE_A registered, neitlner AS norTHIG nor IMS-ALG 

involved, in SU case dialog initiated between UE_A and UE_B 
Test configuration for: 

Unsuccessful initiai requests and responses from UE_A 
Example: 

Initial INVITE in IMS VoiP voice call from UE A 



Figure 3: CF_M02-SS1-MT2b 



l-CSCF 



V J 



PO 




Precondition: 

Different network operators performing origination and termination (SS1), UE_A in Home network A 
(M02), UE_B in Home network B (MT2), both UEs registered, DNS server involved in networks, 
neither AS norTHIG nor lIvlS-ALG involved, in SU case dialog initiated between UE_A and UE_B 

Test configuration for: 

Initial requests and responses between UE_A and UE_B 

Example: 

Initial INVITE in lIvIS VoIP voice call from UE_A 

Figure 4: CF_l\fl02-SS1-IVIT2c 
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Gm 



^ 



PCO 



IMS A 



P-CSCF 



HSS 



S-CSCF 



l-CSCF 



Mw 



HSS 



IMS B 




PCO 



UE 



AS 



Precondition: 

Different networf; operators performing origination and termination (SS1), UE_A in Home netvvorf; A 

(M0#2), UE_B in Home networl<B (MT#2), AS_B discovered based on service iogic in Home networl< 

B (AST#4), oniy UE_A registered, in SU case dialog initiated between UE_A and AS_B, neither THiG 

nor iMS-ALG involved 
Test configuration for: 

initial (IN) and Subsequent (SU) requests and responses between UE_A and AS_B 
Example: 

IN, Initial INVITE, IMS VoIP voice call from UE_A forwarded to AS_B as a result of filter criteria. ASB 
acts as routing AS 

SU: BYE request, UE_A terminates IMS VoIP voice call towards AS_B 



Figures: CF_M02-SS1-MT2-AST4 




AS 
B 



Precondition: 

Different network operators performing origination and termination (SS1), UE_A in Home network A 
(M0#2), UE_B in Home network B (MT#2), AS_B discovered based on servce logic in Home network 
B (AST#4), only UE_A registered, AS_B not responding, neither THIG nor IMS-ALG involved 

Test configuration for: 

Initial (IN) and Subsequent (SU) requests and responses between UE_A and AS_B 

Example: 

IN: Unsuccessful initial INVITE, IMS VoIP voice call from UE_Afowjarded to AS_B as a result of 
filter criteria but no response 

Figure 6: CF_l\fl02-SS1-l\flT2-AST4b 

NOTE: The configuration CF_M02-SSl-MT2-AST4b does not require a physical appHcation server for IMS B. 
Fiher criteria in IMS B should only be set to forward SIP messages to an IP address which does not 
respond to forwarded SIP messages. 



4.4 



Use Cases 



Use cases are the basis for interoperability test descriptions. Each use case defines both a generic test sequence, i.e. a set 
of user stimuli and observations for any number of involved IMS external entities (IMS UE, DNS Server, and AS), and 
a monitor view of all the resulting messages exchanged at the outer IMS core network interfaces, i.e. a call flow for 
user, Gm, DNS, and ISC interfaces. Test sequence and call flow are correlated using grey shading. 

All of the use cases presented in this clause that involve UE interaction assume are assumed to follow one of the 
registration and subscriptions described in clause 4.2.4 for each UE involved in the test. They are not shown here. 



ETSI 



19 



ETSI TS 186 011-2 VI. 1.1 (2009-03) 



Test descriptions defined in clause 5 then reference and specialize one of these use cases presented in this clause, 
i.e. generic test sequence and call flow, according to the needs of the one or more test purposes which are associated 
with a test description. 

4.4.1 User-initiated VoIP call setup and release 
4.4.1.1 Normal Call 
4.4.1.1.1 Description 

UE_A places an IMS VoIP call to UE_B. Once the media path is established, the originating user releases the call. We 
assume support for reliable provisional responses (lOOrel) and no SDP preconditions. The call flow path and node 
configuration for this use case corresponds to CF_M02-SS1-MT2. 

The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering): 



1 


User A calls User B (CFW step 1 ) 


2 


User B is informed of incoming call of User A (CFW step 8) 


3 


User A is informed that UE B is ringing (CFW step 12) 


4 


User B answers call (CFW step 19) 


5 


User A is presented that call in process (CFW step 23) 


6 


User B is informed that the call is in progress (CFW step 27) 


7 


User A ends call (CFW step 28) 


8 


User B is informed that call has ended (CFW step 32) 



4.4.1 .1 .2 UC_01 : SIP Call Flow "Normal Call" 

For a call with reliable provisional responses (lOOrel) and no SDP preconditions, the expected sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 
lUI 

s 

B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A calls User B 


2 






^ 










INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


3 






^ 










100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


4 








^ 








INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


5 








^ 








100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


6 










^ 






INVITE 


IMS B P-CSCF forwards INVITE to UE B 


7 










^ 






100 Trying 


UE_B responds with a 100 Trying provisional 
response 


8 












^ 






User B is informed of incoming call of User A 


9 










^ 






180 Ringing 


UE_B responds to initial INVITE with 180 Ringing to 
indicate that it has started alerting 


10 








^ 








180 Ringing 


IMS B S-CSCF forwards 180 Ringing response to 
IMS A S-CSCF 


11 






^ 










180 Ringing 


IMS A P-CSCF forwards the 180 Ringing response 
toUE A 


12 




^ 














User A is informed that UE B is ringing 


13 






^ 










PRACK 


UE_A acknowledges the receipt of 180 response by 
sending PRACK 


14 








^ 








PRACK 


IMS A S-CSCF forwards PRACK to IMS B 
S-CSCF 


15 










^ 






PRACK 


IMS B P-CSCF forwards PRACK to UE B 


16 










^ 






200 OK 


UE B responds PRACK with 200 OK 
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Step 


Direction 


IVIessage 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






17 








^ 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


18 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


19 












^ 






User B answers call 


20 










^ 






200 OK 


UE_B responds INVITE with 200 OK to indicate that 
the call has been answered 


21 








^ 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


22 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


23 




^ 














User A is presented that call in process 


24 






^ 










ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


25 








^ 








ACK 


IMS A S-CSCF forwards ACK to IMS B S-CSCF 


26 










^ 






ACK 


IMS B P-CSCF forwards ACK to UE B 


27 












^ 






User B is informed that the call is in progress 


28 




^ 














User A ends call 


29 






^ 










BYE 


UE A releases the call with BYE 


30 








^ 








BYE 


IMS A S-CSCF forwards BYE to IMS B S-CSCF 


31 










^ 






BYE 


IMS B P-CSCF forwards BYE to UE B 


32 












^ 






User B is informed that call has ended 


33 










^ 






200 OK 


UE B sends 200 OK for BYE 


34 








4- 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


35 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 



4.4.1 .2 Temporarily unavailable 
4.4.1.2.1 Description 

UE_A places an IMS VoIP call to UE_B. UE_B is not registered. The call flow path and node configuration for this use 
case corresponds to CF_M02-SS1-MT2. 

The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering): 



User A calls User B (CFW step 1) 



User A is informed of User B unreachable (CFW step 8) 



£75/ 



21 



ETSI TS 186 011-2 VI. 1.1 (2009-03) 



4.4.1 .2.2 UC_02: SIP Call Flow "Temporarily unavailable" 



Step 


Direction 


IVIessage 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

lUI 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A calls User B 


2 






^ 










INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


3 






4- 










100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


4 








-» 








INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


5 








^ 








100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


6 








^ 








480 Temporarily unavailable 


IMS_B l-CSCF generates error message indicating 
unavailable user 


7 






^ 










480 Temporarily unavailable 


IMS A P-CSCF forwards error response to UE A 


8 




^ 














User A is informed of User B unreachable 



4.4.1 .3 Temporarily unavailable (Application Server) 
4.4.1.3.1 Description 

UE_A places an IMS VoIP call to UE_B. UE_B is not registered. The call flow path and node configuration for this use 
case corresponds to CF_M02-SS1-MT2. 



The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering): 



User A calls User B (CFW step 1 ) 



User A is informed of User B unreachable (CFW step 8) 



4.4.1 .3.2 UC_03: SIP Call Flow "Temporarily unavailable" (Application Server) 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 
lUI 

s 

B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A calls User B 


2 






^ 










INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


3 






^ 










100 Trying 


iMS_A P-CSCF responds with a 100 Trying 
provisional response 


4 








■^ 








INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


5 








«- 








100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


6 








^ 








408 Request Timeout or 
5xx Response 


IMS_B l-CSCF forwards S-CSCF error message 
indicating unreachable AS 


7 






^ 










408 Request Timeout or 
5xx Response 


IMS_A P-CSCF forwards error response to UE_A 


8 




4- 














User A is informed of "not reachable" 



£75/ 



22 



ETSI TS 186 011-2 VI. 1.1 (2009-03) 



4.4.1 .4 Cancelled session setup 
4.4.1.4.1 Description 

UE_A places an IMS VoIP call to UE_B. The call request will be cancelled by UE_A before the call is answered. The 
call flow path and node configuration for this use case corresponds to CF_M02-SS1-MT2. 

The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering): 



1 


User A calls User B (CFW step 1) 


2 


User B is informed of incoming call of User A (CFW step 8) 


3 


User A is informed that UE B is ringing (CFW step 12) 


4 


User A cancel ringing (CFW step 19) 


5 


User B informed that call is aborted (CFW step 26) 



4.4.1 .4.2 UC 04: SIP Call Flow "Cancelled" 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A calls User B 


2 






^ 










INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


3 






4- 










lOOTrying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


4 








^ 








INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


5 








^ 








lOOTrying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


6 










^ 






INVITE 


IMS B P-CSCF forwards INVITE to UE B 


7 










^ 






lOOTrying 


UE_B responds with a 100 Trying provisional 
response 


8 












^ 






User B is informed of incoming call of User A 


9 










^ 






180 Ringing 


UE_B responds to initial INVITE with 180 Ringing to 
indicate that it has started alerting 


10 








^ 








180 Ringing 


IMS B S-CSCF forwards 180 Ringing response to 
IMS A S-CSCF 


11 






^ 










180 Ringing 


IMS A P-CSCF forwards the 180 Ringing response 
toUE A 


12 




4- 














User A is informed that UE B is ringing 


13 






^ 










PRACK 


UE_A acknowledges the receipt of 180 response by 
sending PRACK 


14 








^ 








PRACK 


IMS A S-CSCF forwards PRACK to IMS B 
S-CSCF 


15 










^ 






PRACK 


IMS B P-CSCF forwards PRACK to UE B 


16 










^ 






200 OK 


UE B responds PRACK with 200 OK 


17 








4- 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


18 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


19 




^ 














User A cancel ringing 


20 






^ 










CANCEL 


UE A sends CANCEL to abort call 


21 






^ 










200 OK 


IMS A P-CSCF responds with a 200 OK response 


22 








^ 








CANCEL 


IMS A S-CSCF sends CANCEL to IMS B S-CSCF 


23 








^ 








200 OK 


IMS B S-CSCF responds with a 200 OK response 


24 










^ 






CANCEL 


IMS B P-CSCF sends CANCEL to UE B 


25 










^ 






200 OK 


UE B responds with a 200 OK response 


26 












^ 






User B informed that call is aborted 


27 










^ 






487 Request Terminated 


UE_B confirms cancellation of the INVITE request 
with a 487 Request Terminated error response 
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Step 


Direction 


IVIessage 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






28 










^ 






ACK 


IIVIS B P-CSCF responds witli an ACK to UE B 


29 








^ 








487 Request Terminated 


IMS_B S-CSCF sends a 487 Request Terminated 
error response to IIVIS A S-CSCF 


30 








^ 








ACK 


IMS A S-CSCF responds with an ACK 


31 






«- 










487 Request Terminated 


IMS_B P-CSCF sends a 487 Request Terminated 
error response to UE A 


32 






-> 










ACK 


UE A responds with an ACK 



4.4.1.5 Not Found 



4.4.1.5.1 Description 

UE_A places an IMS VoIP call to UE_B. UE_B is no user of IMS_B. The call flow path and node configuration for this 
use case corresponds to CF_M02-SS1-MT2. 

The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering): 



User A calls User B (CFW step 1 ) 



User A is informed of User B unreachable (CFW step 8) 



4.4.1.5.2 UC 05: SIP Call Flow "Not Found" 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A calls User B 


2 






^ 










INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


3 






^ 










100 Trying 


IIVIS_A P-CSCF responds with a 100 Trying 
provisional response 


4 








^ 








INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


5 








4- 








100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


6 








^ 








404 Not Found or 

604 Does not exist anywhere 


IMS_B l-CSCF generates error message indicating 
non-existent user 


7 






^ 










404 Not Found or 

604 Does not exist anywhere 


IMS_A P-CSCF forwards error response to UE_A 


8 




^ 














User A is informed of "no such user" 



4.4.2 User-initiated call hold and resume 

UE_A places an IMS VoIP call to UE_B. Once the media path is established, the originating user puts the call on hold, 
stopping the media stream. The originating user then resumes the call. The call flow path and node configuration for 
this use case corresponds to CF_M02-SS1-MT2. We assume reliable provisional responses (lOOrel) and no SDP 
preconditions. Depending on the UE this feature may be implemented either using relNVITE or UPDATE where 
UPDATE is only an optional feature. 
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4.4.2.1 User-initiated call hold and resume with relNVITE 
4.4.2.1.1 Description 

The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering): 



1 


User A calls User B (CFW step 1 ) 


2 


User B is informed of incoming call of User A (CFW step 8) 


3 


User A is informed that UE B is ringing (CFW step 12) 


4 


User B answers call (CFW step 19) 


5 


User A is presented that call is in progress (CFW step 23) 


6 


User B is presented that call is in progress (CFW step 27) 


7 


User A puts call on hold (CFW step 28) 


8 


User B is informed that call on hold (CFW step 35) 


9 


User A resumes call (CFW step 42) 


10 


User B is informed the call is resumed (CFW step 49) 


11 


User A is informed that call is resumed (CFW step 53) 


12 


User A ends call (CFW step 57) 


13 


User B is informed the call has ended (CFW step 61) 



4.4.2.1 .2 UC 06: SIP Call Flow "call hold and resume" with relNVITE 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




-» 














User A calls User B 


2 






^ 










INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


3 






^ 










100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


4 








^ 








INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


5 








^ 








100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


6 










^ 






INVITE 


IMS B P-CSCF forwards INVITE to UE B 


7 










^ 






100 Trying 


UE_B responds with a 100 Trying provisional 
response 


8 


















User B is informed of incoming call of User A 


9 










^ 






180 Ringing 


UE_B responds to initial INVITE with 180 Ringing to 
indicate that it has started alerting 


10 








^ 








180 Ringing 


IMS B S-CSCF forwards 180 Ringing response to 
IMS A S-CSCF 


11 






^ 










180 Ringing 


IMS A P-CSCF forwards the 180 Ringing response 
toUE A 


12 




^ 














User A is informed that UE B is ringing 


13 






^ 










PRACK 


UE_A acknowledges the receipt of 180 response by 
sending PRACK 


14 








■^ 








PRACK 


IMS A S-CSCF forwards PRACK to IMS B 
S-CSCF 


15 










^ 






PRACK 


IMS B P-CSCF forwards PRACK to UE B 


16 










^ 






200 OK 


UE B responds to PRACK with 200 OK 


17 








^ 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


18 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


19 












^ 






User B answers call 


20 










^ 






200 OK 


UE_B responds to INVITE with 200 OK to indicate 
that the call has been answered 


21 








«- 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 
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Step 


Direction 


IVIessage 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






22 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


23 




^ 














User A is presented that call is in progress 


24 






^ 










ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


25 








^ 








ACK 


IMS A S-CSCF forwards ACK to IMS B S-CSCF 


26 










^ 






ACK 


IMS B P-CSCF forwards ACK to UE B 


27 












^ 






User B is presented that call is in progress 


28 




^ 














User A puts call on hold 


29 






^ 










INVITE 


UE_A sends relNVITE message indicating media 
stream inactive (Call Hold) 


30 






^ 










100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


31 








-» 








INVITE 


IMS A S-CSCF forwards INVITE to IMS B S-CSCF 


32 








^ 








100 Trying 


IMS_B S-CSCF responds with a 100 Trying 
provisional response 


33 










^ 






INVITE 


IMS B P-CSCF forwards INVITE to UE B 


34 










^ 






100 Trying 


UE_B responds with a 100 Trying provisional 
response 


35 


















User B is informed that call on hold 


36 










^ 






200 OK 


UE_B responds to INVITE with 200 OK indicating 
media stream inactive 


37 








4- 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


38 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


39 






-> 










ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


40 








^ 








ACK 


IMS A S-CSCF forwards ACK to IMS B S-CSCF 


41 










^ 






ACK 


IMS B P-CSCF forwards ACK to UE B 


42 


















User A resumes call 


43 






^ 










INVITE 


UEA sends relNVITE message indicating media 
stream active (Call Resume) 


44 






^ 










100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


45 








■^ 








INVITE 


IMS A S-CSCF forwards INVITE to IMS B S-CSCF 


46 








«- 








100 Trying 


IMS_B S-CSCF responds with a 100 Trying 
provisional response 


47 










^ 






INVITE 


IMS B P-CSCF forwards INVITE to UE B 


48 










^ 






100 Trying 


UE_B responds with a 100 Trying provisional 
response 


49 


















User B is informed the call is resumed 


50 










^ 






200 OK 


UE_B responds to UPDATE with 200 OK indicating 
media stream active 


51 








^ 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


52 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


53 


















User A is informed that call is resumed 


54 






^ 










ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


55 








^ 








ACK 


IMS A S-CSCF forwards ACK to IMS B S-CSCF 


56 










^ 






ACK 


IMS B P-CSCF forwards ACK to UE B 


57 


















User A ends call 


58 






^ 










BYE 


UEA releases the call with BYE 


59 








^ 








BYE 


IMS A S-CSCF forwards BYE to IMS B S-CSCF 


60 










^ 






BYE 


IMS B P-CSCF forwards BYE to UE B 


61 


















User B is informed the call has ended 


62 










^ 






200 OK 


UE B sends 200 OK for BYE 
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Step 


Direction 


IVIessage 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






63 








^ 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


64 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 



4.4.2.2 User-initiated call hold and resume with UPDATE 
4.4.2.2.1 Description 

The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering): 



1 


User A calls User B (CFW step 1 ) 


2 


User B is informed of incoming call of User A (CFW step 8) 


3 


User A is informed that UE B is ringing (CFW step 12) 


4 


User B answers call (CFW step 19) 


5 


User A is informed that call is in progress (CFW step 23) 


6 


User B is informed that call is in progress (CFW step 27) 


7 


User A put call on hold (CFW step 28) 


8 


User B is informed that call on hold (CFW step 32) 


9 


User A resumes call (CFW step 36) 


10 


User B is informed the call is resumed (CFW step 40) 


11 


User A is informed that call is resumed (CFW step 44) 


12 


User A ends call (CFW step 45) 


13 


User B is informed the call has ended (CFW step 49) 



4.4.2.2.2 UC_07: SIP Call Flow "call hold and resume" with UPDATE 
The expected sequence: 



step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A calls User B 


2 






^ 










INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


3 






^ 










100 Trying 


IMS_A P-CSCFW responds with a 100 Trying 
provisional response 


4 








^ 








INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


5 








<- 








100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


6 










^ 






INVITE 


IMS B P-CSCF forwards INVITE to UE B 


7 










<- 






100 Trying 


UE_B responds with a 100 Trying provisional 
response 


8 












^ 






User B is informed of incoming call of User A 


9 










^ 






180 Ringing 


UE_B responds to initial INVITE with 180 Ringing to 
indicate that it has started alerting 


10 








^ 








180 Ringing 


IMS B S-CSCF forwards 180 Ringing response to 
IMS A S-CSCF 


11 






^ 










180 Ringing 


IMS A P-CSCF forwards the 180 Ringing response 
toUE A 


12 




«- 














User A is informed that UE B is ringing 
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Step 


Direction 


IVIessage 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






13 






^ 










PRACK 


UE_A acknowledges the receipt of 180 response by 
sending PRACK 


14 








-> 








PRACK 


IMS A S-CSCF forwards PRACK to IMS B 
S-CSCF 


15 










^ 






PRACK 


IMS B P-CSCF forwards PRACK to UE B 


16 










^ 






200 OK 


UE B responds to PRACK with 200 OK 


17 








«- 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


18 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


19 


















User B answers call 


20 










^ 






200 OK 


UE_B responds to INVITE with 200 OK to indicate 
that the call has been answered 


21 








^ 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


22 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


23 




^ 














User A is informed that the call is in progress 


24 






^ 










ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


25 








■^ 








ACK 


IMS A S-CSCF forwards ACK to IMS B S-CSCF 


26 










^ 






ACK 


IMS B P-CSCF forwards ACK to UE B 


27 












^ 






User B is informed that call is in progress 


28 




^ 














User A put call on hold 


29 






-^ 










UPDATE 


UE_A sends UPDATE message indicating media 
stream inactive (Call Hold) 


30 








-» 








UPDATE 


IMS A S-CSCF forwards UPDATE to IMS B 
S-CSCF 


31 










^ 






UPDATE 


IMS B P-CSCF forwards UPDATE to UE B 


32 












^ 






User B is informed that call on hold 


33 










^ 






200 OK 


UE_B responds to UPDATE with 200 OK indicating 
media stream inactive 


34 








^ 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


35 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


36 




^ 














User A resumes call 


37 






^ 










UPDATE 


UE_A sends UPDATE message indicating media 
stream active (Call Resume) 


38 








^ 








UPDATE 


IMS A S-CSCF forwards UPDATE to IMS B 
S-CSCF 


39 










^ 






UPDATE 


IMS B P-CSCF forwards UPDATE to UE B 


40 












^ 






User B is informed the call is resumed 


41 










^ 






200 OK 


UE_B responds to UPDATE with 200 OK indicating 
media stream active 


42 








«- 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


43 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


44 




^ 














User A is informed that call is resumed 


45 




^ 














User A ends call 


46 






^ 










BYE 


UE A releases the call with BYE 


47 








^ 








BYE 


IMS A S-CSCF forwards BYE to IMS B S-CSCF 


48 










^ 






BYE 


IMS B P-CSCF forwards BYE to UE B 


49 












^ 






User B is informed the call has ended 


50 










^ 






200 OK 


UE B sends 200 OK for BYE 


51 








^ 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


52 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 
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4.4.3 S-CSCF initiated session release 
4.4.3.1 Release from originating network 
4.4.3.1.1 Description 

UE_A places an IMS VoIP call to UE_B. Once the media path is established, the session is released by the originating 
network through a forced user de-registration at the HSS in IMS_A. The call flow path and node configuration for this 
use case corresponds to CF_M02-SS1-MT2. We assume provisional responses (lOOrel) and no SDP preconditions. 

The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering): 



1 


User A calls User B (CFW step 1) 


2 


User B is informed of incoming call of User A (CFW step 8) 


3 


User A is informed that UE B is ringing (CFW step 12) 


4 


User B answers call (CFW step 19) 


5 


User A is informed that the call is in progress (CFW step 23) 


6 


User B is informed that call is in progress (CFW step 27) 


7 


User B is informed the call has ended (CFW step 30) 


8 


User A is informed the call has ended 



4.4.3.1 .2 UC_08: SIP Call flow for Session release from originating network 



Step 


Direction 


IVIessage 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A calls User B 


2 






^ 










INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


3 






^ 










100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


4 








^ 








INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


5 








^ 








100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


6 










^ 






INVITE 


IMS B P-CSCF forwards INVITE to UE B 


7 










<- 






100 Trying 


UE_B responds with a 100 Trying provisional 
response 


8 












^ 






User B is informed of incoming call of User A 


9 










^ 






180 Ringing 


UE_B responds to initial INVITE with 180 Ringing to 
indicate that it has started alerting 


10 








^ 








180 Ringing 


IMS B S-CSCF forwards 180 Ringing response to 
IMS A S-CSCF 


11 






^ 










180 Ringing 


IMS A P-CSCF forwards the 180 Ringing response 
toUE A 


12 




^ 














User A is informed that UE B is ringing 


13 






-> 










PRACK 


UE_A acknowledges the receipt of 180 response by 
sending PRACK 


14 








^ 








PRACK 


IMS A S-CSCF forwards PRACK to IMS B 
S-CSCF 


15 










-^ 






PRACK 


IMS B P-CSCF forwards PRACK to UE B 


16 










^ 






200 OK 


UE B responds PRACK with 200 OK 


17 








^ 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


18 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


19 












^ 






User B answers call 


20 










^ 






200 OK 


UE_B responds INVITE with 200 OK to indicate that 
the call has been answered 
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Step 


Direction 


IVIessage 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






21 








^ 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


22 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


23 




^ 














User A is informed that the call is in progress 


24 






^ 










ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


25 








^ 








ACK 


IMS A S-CSCF forwards ACK to IMS B S-CSCF 


26 










^ 






ACK 


IMS B P-CSCF forwards ACK to UE B 


27 












^ 






User B is informed that call is in progress 


28 








^ 








BYE 


IMS_A S-CSCF releases the call towards the called 
user with BYE 


29 










^ 






BYE 


IMS B P-CSCF forwards BYE to UE B 


30 












^ 






User B is informed the call has ended 


31 










^ 






200 OK 


UE B sends 200 OK for BYE 


32 








^ 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


33 






^ 










BYE 


IMS_A S-CSCF releases the call towards the calling 
user with BYE 


34 




^ 














User A is informed the call has ended 


35 






^ 










200 OK 


UE A sends 200 OK for BYE 



4.4.3.2 Release from terminating network 
4.4.3.2.1 Description 

UE_A places an IMS VoIP call to UE_B. Once the media path is established, the session is released by the terminating 
network through a forced user de-registration at the HSS in IMS_B. The call flow path and node configuration for this 
use case corresponds to CF_M02-SS1-MT2. We assume provisional responses (lOOrel) and no SDP preconditions. 

The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering): 



1 


User A calls User B (CFW step 1) 


2 


User B is informed of incoming call of User A (CFW step 8) 


3 


User A is informed that UE B is ringing (CFW step 12) 


4 


User B answers call (CFW step 19) 


5 


User A is informed that the call is in progress (CFW step 23) 


6 


User B is informed that call is in progress (CFW step 27) 


7 


User A is informed the call has ended (CFW step 30) 


8 


User B is informed the call has ended (CFW step 34) 
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4.4.3.2.2 UC_09: SIP Call flow for Session release from terminating network 



Step 


Direction 


IVIessage 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

lUI 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A calls User B 


2 






^ 










INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


3 






4- 










100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


4 








-» 








INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


5 








^ 








100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


6 










^ 






INVITE 


IMS B P-CSCF forwards INVITE to UE B 


7 










^ 






100 Trying 


UE_B responds with a 100 Trying provisional 
response 


8 












^ 






User B is informed of incoming call of User A 


9 










^ 






180 Ringing 


UE_B responds to initial INVITE with 180 Ringing to 
indicate that it has started alerting 


10 








^ 








180 Ringing 


IMS B S-CSCF forwards 180 Ringing response to 
IMS A S-CSCF 


11 






^ 










180 Ringing 


IMS A P-CSCF forwards the 180 Ringing response 
toUE A 


12 




^ 














User A is informed that UE B is ringing 


13 






^ 










PRACK 


UE_A acknowledges the receipt of 180 response by 
sending PRACK 


14 








-^ 








PRACK 


IMS A S-CSCF forwards PRACK to IMS B 
S-CSCF 


15 










^ 






PRACK 


IMS B P-CSCF forwards PRACK to UE B 


16 










^ 






200 OK 


UE B responds PRACK with 200 OK 


17 








^ 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


18 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


19 












4- 






User B answers call 


20 










«- 






200 OK 


UE_B responds INVITE with 200 OK to indicate that 
the call has been answered 


21 








«- 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


22 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


23 




^ 














User A is informed that the call is in progress 


24 






-» 










ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


25 








-> 








ACK 


IMS A S-CSCF forwards ACK to IMS B S-CSCF 


26 










^ 






ACK 


IMS B P-CSCF forwards ACK to UE B 


27 












^ 






User B is informed that call is in progress 


28 








^ 








BYE 


IMS_B S-CSCF releases the call towards the calling 
user with BYE 


29 






^ 










BYE 


IMS A P-CSCF forwards BYE to UE B 


30 




^ 














User A is informed the call has ended 


31 






^ 










200 OK 


UE A sends 200 OK for BYE 


32 








^ 








200 OK 


IMS A S-CSCF forwards 200 OK response to 
IMS B S-CSCF 


33 










^ 






BYE 


IMS_B S-CSCF releases the call towards the called 
user with BYE 


34 












^ 






User B is informed the call has ended 


35 










^ 






200 OK 


UE B sends 200 OK for BYE 
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4.4.4 P-CSCF initiated session release 

4.4.4.1 Resources missing before session establishment 

4.4.4.2 Description 

An internal message reports to the P-CSCF the loss of resource (e.g. radio resources). If a dialog initiation is started, but 
not yet estabUshed, then the P-CSCF will CANCEL the requests. 

If a UE_A Originated dialog is established then the call will be released by the P-CSCF (in IMS_A). If a UE_B 
Originated dialog is established then the call will be released by the P-CSCF (in IMS_A). The call flow path and node 
configuration for this use case corresponds to CF_M02-SS1-MT2. 

The test sequence typically associated with this use case when an established session is released is as follows (CFW 
step numbers refer the call flow step numbering): 



1 


User A calls User B (CFW step 1) 


2 


User B is informed of incoming call of User A (CFW step 8) 


3 


User A is informed that UE B is ringing (CFW step 12) 


4 


Internal a message that resources for UE A are not available (CFW step 19) 


5 


User B is informed the call has ended (CFW step 25) 



4.4.4.2.1 DC 1 0: SIP Call flow for Session establishment cancelled 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A calls User B 


2 






^ 










INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


3 






«- 










100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


4 








^ 








INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


5 








4- 








100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


6 










^ 






INVITE 


IMS B P-CSCF forwards INVITE to UE B 


7 










<- 






100 Trying 


UE_B responds with a 100 Trying provisional 
response 


8 












^ 






User B is informed of incoming call of User A 


9 










^ 






180 Ringing 


UE_B responds to initial INVITE with 180 Ringing to 
indicate that it has started alerting 


10 








^ 








180 Ringing 


IMS B S-CSCF forwards 180 Ringing response to 
IMS AS-CSCF 


11 






^ 










180 Ringing 


IMS A P-CSCF forwards the 180 Ringing response 
toUE A 


12 




^ 














User A is informed that UE B is ringing 


13 






-^ 










PRACK 


UE_A acknowledges the receipt of 180 response by 
sending PRACK 


14 








^ 








PRACK 


IMS A S-CSCF forwards PRACK to IMS B 
S-CSCF 


15 










-> 






PRACK 


IMS B P-CSCF forwards PRACK to UE B 


16 










^ 






200 OK 


UE B responds PRACK with 200 OK 


17 








^ 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS AS-CSCF 


18 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


19 
















LOSS 


Internal a message that resources for UEA are not 
available 


20 








^ 








CANCEL 


IMS A sends CANCEL to IMS B 
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Step 


Direction 


IVIessage 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






22 








^ 








200 OK 


IMS B S-CSCF responds with a 200 OK 


23 










^ 






CANCEL 


IMS B sends CANCEL to UE B 


24 










^ 






200 OK 


UE B responds with 200 OK 


25 












^ 






User B is informed the call has ended 


26 










^ 






437 Request Terminated 


UE B S-CSCF sends 437 Request Terminated to 
IMS B 


27 










-» 






ACK 


IMS B responds with ACK 


28 








^ 








437 Request Terminated 


IMS B sends 437 Request Terminated to IMS A 


29 








^ 








ACK 


IMS A responds with ACK 



4.4.4.3 Resources missing on originator network within session 
4.4.4.3.1 Description 

If a UE_A Originated dialog is established then the call will be released by the P-CSCF (in IMS_A). The call flow path 
and node configuration for this use case corresponds to CF_M02-SS1-MT2. 



1 


User A calls User B (CFW step 1 ) 


2 


User B is informed of incoming call of User A (CFW step 8) 


3 


User A is informed that UE B is ringing (CFW step 12) 


4 


User B answers call (CFW step 19) 


5 


User A is informed that the call is in progress (CFW step 23) 


6 


User B is informed that call is in progress (CFW step 27) 


7 


PDF or SPDF sends a message that resources are missing for UE A (CFW step 28) 


8 


User B is informed the call has ended (CFW step 31) 



4.4.4.3.2 UC_1 1 : SIP Call flow for Session release from originating network 



Step 


Direction 


IVIessage 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A calls User B 


2 






^ 










INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


3 






^ 










100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


4 








-» 








INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


5 








«- 








100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


6 










^ 






INVITE 


IMS B P-CSCF forwards INVITE to UE B 


7 










^ 






100 Trying 


UE_B responds with a 100 Trying provisional 
response 


8 












^ 






User B is informed of incoming call of User A 


9 










^ 






180 Ringing 


UE_B responds to initial INVITE with 180 Ringing to 
indicate that it has started alerting 


10 








^ 








180 Ringing 


IMS B S-CSCF forwards 180 Ringing response to 
IMS A S-CSCF 


11 






^ 










180 Ringing 


IMS A P-CSCF forwards the 180 Ringing response 
toUE A 


12 




^ 














User A is informed that UE B is ringing 


13 






^ 










PRACK 


UE_A acknowledges the receipt of 180 response by 
sending PRACK 
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Step 


Direction 


IVIessage 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






14 








^ 








PRACK 


IMS A S-CSCF forwards PRACK to IMS B 
S-CSCF 


15 










^ 






PRACK 


IMS BP-CSCF forwards PRACK to UE B 


16 










^ 






200 OK 


UE B responds PRACK with 200 OK 


17 








^ 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


18 






4- 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


19 












^ 






User B answers call 


20 










^ 






200 OK 


UE_B responds INVITE with 200 OK to indicate that 
the call has been answered 


21 








^ 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


22 






«- 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


23 




^ 














User A is informed that the call is in progress 


24 






^ 










ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


25 








■^ 








ACK 


IMS A S-CSCF forwards ACK to IMS B S-CSCF 


26 










^ 






ACK 


IMS B P-CSCF forwards ACK to UE B 


27 


















User B is informed that call is in progress 


28 
















LOSS 


PDF or SPDF sends a message that resources are 
missing for UE A 


29 








^ 








BYE 


IMS A P-CSCF sends BYE to IMS B S-CSCF 


30 










^ 






BYE 


IMS B P-CSCF forwards BYE to UE B 


31 












■^ 






User B is informed the call has ended 


32 










^ 






200 OK 


UE B sends 200 OK for BYE 


33 








^ 








200 OK 


IMS_B forwards 200 OK response to IMS_A 



4.4.4.4 Resources missing on terminating network within session 
4.4.4.4.1 Description 

If a UE_A Originated dialog is established then the call will be released by the P-CSCF (in IMS_B). If a UE_ The call 
flow path and node configuration for this use case corresponds to CF_M02-SS1-MT2. 



1 


User A calls User B (CFW step 1) 


2 


User B is informed of incoming call of User A (CFW step 8) 


3 


User A is informed that UE B is ringing (CFW step 12) 


4 


User B answers call (CFW step 19) 


5 


User A is informed that the call is in progress (CFW step 23) 


6 


User B is informed that call is in progress (CFW step 27) 


7 


PDF or SPDF sends a message that resources are missing for UE_B (CFW step 28) 


8 


User A is informed the call has ended (CFW step 31) 
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4.4.4.4.2 UC_1 2: SIP Call flow for Session release from terminating network 



Step 


Direction 


IVIessage 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

lUI 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A calls User B 


2 






^ 










INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


3 






4- 










100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


4 








-» 








INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


5 








^ 








100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


6 










^ 






INVITE 


IMS B P-CSCF forwards INVITE to UE B 


7 










^ 






100 Trying 


UE_B responds with a 100 Trying provisional 
response 


8 












^ 






User B is informed of incoming call of User A 


9 










^ 






180 Ringing 


UE_B responds to initial INVITE with 180 Ringing to 
indicate that it has started alerting 


10 








^ 








180 Ringing 


IMS B S-CSCF forwards 180 Ringing response to 
IMS A S-CSCF 


11 






^ 










180 Ringing 


IMS A P-CSCF forwards the 180 Ringing response 
toUE A 


12 




^ 














User A is informed that UE B is ringing 


13 






^ 










PRACK 


UE_A acknowledges the receipt of 180 response by 
sending PRACK 


14 








-^ 








PRACK 


IMS A S-CSCF forwards PRACK to IMS B 
S-CSCF 


15 










^ 






PRACK 


IMS B P-CSCF forwards PRACK to UE B 


16 










^ 






200 OK 


UE B responds PRACK with 200 OK 


17 








^ 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


18 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


19 












4- 






User B answers call 


20 










^ 






200 OK 


UE_B responds INVITE with 200 OK to indicate that 
the call has been answered 


21 








«- 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


22 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


23 




^ 














User A is informed that the call is in progress 


24 






-» 










ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


25 








-> 








ACK 


IMS A S-CSCF forwards ACK to IMS B S-CSCF 


26 










^ 






ACK 


IMS B P-CSCF forwards ACK to UE B 


27 












^ 






User B is informed that call is in progress 


28 
















LOSS 


PDF or SPDF(in IMS_B) sends a message that 
resources are missing for UE B 


29 








^ 








BYE 


IMS B P-CSCF sends BYE to IMS A S-CSCF 


30 






«- 










BYE 


IMS A P-CSCF forwards BYE to UE A 


31 




^ 














User A is informed the call has ended 


32 






^ 










200 OK 


UE A sends 200 OK for BYE 


33 








^ 








200 OK 


IMS A forwards 200 OK response to IMS B 



4.4.5 IMS message exchange between UEs in different networks 
4.4.5.1 Description 

The UE A sends a MESSAGE to UE B located in a different network. 
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The test sequence typically associated with this use case when an established session is released is as follows (CFW 
step numbers refer the call flow step numbering): 



User A sends an instant message (CFW step 1 ) 



User B is informed about the instant message (CFW step 5) 



Optional: User A is presented a delivery report (CFW step 9) 



4.4.5.2 UC_1 3: SIP Call flow for IMS Message Exchange 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A sends an instant message 


2 






^ 










MESSAGE 


UE A sends MESSAGE to IMS A 


3 








^ 








MESSAGE 


IMS A sends MESSAGE to IMS B 


4 










^ 






MESSAGE 


IMS B sends MESSAGE to UE B 


5 












^ 






User B is informed about the instant message 


6 










^ 






200 OK 


UE B sends 200 OK to IMS B 


7 








^ 








200 OK 


IMS B sends 200 OK to IMS A 


8 






^ 










200 OK 


IMS A sends 200 OK to UE A 


9 




^ 














Optional: User A is presented a delivery report 



4.5 Test descriptions 



This clause introduces interoperability Test Descriptions (TDs) which realize one or more IMS NNI test purposes 
(see TS 186 011-1 [2]). TDs have been designed to cover as few test purposes as possible. However, due to the limited 
test execution control in interoperability testing, a number TDs cover more than one test purpose. 

Each TD is defined on the basis of one of the generic use cases forms presented in the previous clause. Each test 
sequence step in a TD includes also a reference to a specific call flow step of the generic use case. Test PReamble (PR) 
and POstamble (PO) steps in a test sequence only reference call flow steps in a use case. Those call flow steps which 
are associated with the Test Body (TB) are repeated after each TD and include any modifications necessary to adapt the 
generic use case. In the adapted call flow steps that are associated with user interactions are shown shaded and steps 
which have pass criteria are associated with are shown in bold. 

Note that the expected test sequence may only show the Call Flow that affects the test. 
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4.5.1 General Capabilities 



4.5.1 .1 IMS CN components shall support SIP messages greater than 1 500 bytes 



Test description 


Identifier: 


TD IMS 0001 


Summary: 


IMS CN components shall support SIP messages greater than 1 500 bytes 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


IP IMS 4002 01 


IS 1 24 229 [1] {V6.1 3.0), clause 4.2A, f 1 


Use Case ref.: 


UC 13 



Pre-test 
conditions: 



Static configuration as per clause 4.3 

UE_A, UE_B support lOOrel, no SDP preconditions, and TCP 

UE_A, UE_B have no filter criteria defined in HSS 

UE_A, UE_B IP bearers established as per clause 4.2.1 

UE_A configured to use TCP for message transport 

UE_A registered using user_1_priv@ims-a.net as per clause 4.2.3 

UE_B registered using user_1_priv@ims-b.net as per clause 4.2.3 

U E_A, UE_B registered public identities are SIP URIs only 



Test sequence: 



Step 



1 PR 



2 TB 



UE_A is requested to send an instant message with 2 000 byte file to 
"user_1_pub@ims-b.net" (CFW step 1) 



Verify that UE_B receives the message with 2 000 byte file (CFW step 

5) 



Conformance 
criteria: 



Check 



TP_IMS_4002_01 in CFW step 3 (MESSAGE): 
ensure that { 
when { UE_A sends MESSAGE to UE_B 

containing a Message_Body bigger than 1 500 bytes "using TCP" 



} 



then { IMS_B receives the l\/IESSAGE 

containing a Message_Body bigger than 1 500 bytes 
and 

containing a topmost Via_header 
indicating TCP 
and 

UE_B receives MESSAGE 
} 



L 



The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A sends an instant message 


2 






^ 










MESSAGE 


UE A sends MESSAGE to IMS A 


3 








^ 








MESSAGE 


IMS A sends a MESSAGE and IMS B receives 
the MESSAGE via TCP (2 000 bytes) 


4 










^ 






MESSAGE 


IMS B sends MESSAGE to UE B 


5 












^ 






User B is informed about the instant message 


6 










^ 






200 OK 


UE B sends 200 OK to IMS B 


7 








^ 








200 OK 


IMS B sends 200 OK to IMS A 


8 






^ 










200 OK 


IMS A sends 200 OK to UE A 


9 




^ 














Optional: User A is presented a delivery report 
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4.5.2 Initial dialog or standalone request procedures 
4.5.2.1 Standalone request procedures 



4.5.2.1 .1 Standalone MESSAGE request procedure 



Test description 



Identifier: 



TD IMS 0002 



Summary: 



Standalone MESSAGE request procedures 



Configuration: 



OF M02-SS1-MT2 



References 



Test purpose 



IP IMS 5061 02 



TP IMS 5097 06 



IP IMS 5097 07 



TP IMS 5117 02 



TP IMS 5118 01 



Specification reference 



TS 124 229 [1] {V6.13.0), clause 5.2.6.4, 
189 



TS 124 229 [1] {V6.13.0), clause 5.4.3.2, 

u 



TS 124 229 [1] {V6.13.0), clause 5.4.3.2, 

u 



TS 124 229 [1] (V6.13.0), clause 5.4.3.3, 
1149 



TS 124 229 [1] (V6.13.0), clause 5.4.3.3, 
1154 



Use Case ref.: 



UC 13 



Pre-test 
conditions: 



Static configuration as per clause 4.3 

UE_A, UE_B support lOOrel, no SDP preconditions 

UE_A, UE_B have no filter criteria defined in HSS 

UE_A, UE_B IP bearers established as per clause 4.2.1 

UEA registered using user_1_priv@ims-a.net as per clause 4.2.3 

UE_B registered using user_1_priv@ims-b.net as per clause 4.2.3 

UE_A, UE_B registered public identities are SIP URIs only 



Test sequence: 



Step 



1 PR 



2 TB 

SI— 



UE_A is requested to send an instant message to "user_1_pub@ims-b, 
(CFWstepI) 



net" 



Verify that UEB gets the message (CFW step 5) 



I 



Conformance 
criteria: 



Check 



1 



TP_IMS_5061_02 in CFW step 7 (200 OK): 
ensure that { 
when { UEB sends a 2xx_response to UEA } 
then { IMS_A receives the 2xx_response 

not containing P-Preferred-ldentity_header and 
containing P-Asserted-ldentity_header 
containing the address "sent in P-Calied_Party-ID header of the 
standaione request" 
and 

UEA receives the 2xx_response 
} 
1 



TP_IMS_5097_06 in CFW step 3 (MESSAGE): 
ensure that { 
when { UE_A sends a l\/IESSAGE to UE_B } 
then { IMS_B receives the MESSAGE 

containing a P-Charging-Vector_header 
containing an icid_valuej3arameter 
and 

UE_B receives the MESSAGE} 
1 
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Test description 




3 


TP_IMS_5097_07 in CFW step 3 (MESSAGE): 
ensure that { 
when { UE_A sends MESSAGE to UE_B } 
then { IMS_B receives the MESSAGE 

containing a P-Charging-Vector_header 
(containing a orig-ioi_parameter 

indicating ioi of IMS_A and 
not containing a access-networl<-charging-info_parameter) 
and 

not containing a P-Access-Networl<-lnfo_header 
and 
UE B receives the MESSAGE}} 




4 


TP_IMS_51 1 7_02 in CFW step 7 (200 OK): 
ensure that { 
when { UEB sends 2xx_response to UEA } 
then { IMS_A receives the 2xx_response 

containing a P-Charging-Vector_header 
not containing a access-networl<-charging-info_parameter 
and 

not containing a P-Access-Networl<-lnfo_header 
and 

UE A receives the 2xx response } 
} 




5 


TP_IMS_5118_01 in CFW step 7 (200 OK): 
ensure that { 
when { UEB sends 200_response to UEA } 
then { IMS_A receives the 200_response 

containing a P-Charging-Vector_header 
containing a orig-ioi_parameter 

indicating ioi of IMS_A and 
containing a term-ioi_parameter 
indicating ioi of IMS_B 
and 

UE A receives the 200 response } 
} 



The expected test body call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A sends an instant message 


2 






^ 










MESSAGE 


UE A sends MESSAGE to IMS A 


3 








^ 








MESSAGE 


IMS A sends MESSAGE to IMS B 


4 










-> 






MESSAGE 


IMS B sends MESSAGE to UE B 


5 












^ 






User B is informed about the instant message 


6 










<r 






200 OK 


UE B sends 200 OK to IMS B 


7 








<r 








200 OK 


IMS B sends 200 OK to IMS A 


8 






^ 










200 OK 


IMS A sends 200 OK to UE A 


9 




4- 














Optional: User A is presented a delivery report 
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4.5.2.1 .2 Standalone MESSAGE request procedure with implicit Tel URI 



Test description 


Identifier: 


ID IMS 0003 


Summary: 


Standalone MESSAGE request procedures with implicit Tel URI 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP_IMS_5097_08 


TS 124 229 [1] (V6.13.0), clause 5.4.3.2, 

111 


TP IMS 5117 04 


TS 124 229 [1] (V6.13.0), clause 5.4.3.3, 








1149 




Use Case ref.: 


UC_1 3 1 


r 




1 


Pre-test 


• Static configuration as per clause 4.3 




conditions: 


• UE_A, UE_B support 1 0Orel, no SDR preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UEA registered using user_2_priv@ims-a.net as per clause 4.2.3 

• UEB registered using user_2_priv@ims-b.net as per clause 4.2.3 

• UE_A, UE_B implicitly registered public identities include SIP and Tel URIs 

• UE_A, UE_B default public identity is a SIP_URI 


~i 


1 " 

Test sequence: 


Step 




J 


1 PR 


UE A is requested to send an instant message to "user 2 pub@ims-b.net' 








(CFWstepI) 




2 TB 


Verify tliat UE_B gets the message (CFW step 5) 


1 ■ 




J 


Conformance 
criteria: 


Clieck 


1 


1 


TP_IMS_5097_08 in CFW step 3 (MESSAGE): 








ensure that { 








when { UE_A sends MESSAGE to UE_B 








not containing a P-Preferred-ldentity_header or 








containing a P-Preferred-ldentity_header 








not indicating a Tel URI for UE A} 








then { IMS_B receives the MESSAGE 








containing a P-Asserted-ldentity_header 








indicating the default_registered_public_identity of UEA 








and 








containing a P-Asserted-ldentity_header 








indicating a Tel URI of UE A 








and 








UE B receives the MESSAGE} 

} 






2 


TP_IMS_51 1 7_04 in CFW step 7 (200 OK): 
ensure that { 
when { UEB sends 2xx_response to UEA 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
not indicating a Tel_URI of UE_B} 
then { IMS_A receives the 2xx_response 

containing a P-Asserted-ldentity_header 
indicating the default_registered_public_identity of UEB 
and 

containing a P-Asserted-ldentity_header 
indicating a Tel_URI of UE_B 
and 

UE A receives the 2xx response } 
} 
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The expected test body call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A sends an instant message 


2 






^ 










MESSAGE 


UE A sends MESSAGE to IMS A 


3 








■^ 








MESSAGE 


IMS A sends MESSAGE to IMS B 


4 










^ 






MESSAGE 


IMS B sends MESSAGE to UE B 


5 












^ 






User B is informed about the instant message 


6 










<- 






200 OK 


UE B sends 200 OK to IMS B 


7 








<- 








200 OK 


IMS B sends 200 OK to IMS A 


8 






<r 










200 OK 


IMS A sends 200 OK to UE A 


9 




^ 














Optional: User A is presented a delivery report 



4.5.2.1 .3 Standalone MESSAGE request procedure with implicit SIP URI 



Test description 


Identifier: 


TD IMS 0004 


Summary: 


Standalone MESSAGE request procedures with implicit SIP URI 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP_IMS_5097_09 


TS 124 229 [1] (V6.13.0), clause 5.4.3.2, 

f1 


TP IMS 5117 06 


TS 124 229 [1] (V6.13.0), clause 5.4.3.3, 








1149 




Use Case ref.: 


UC 13 1 


-^ 






Pre-test 


• Static configuration as per clause 4.3 




conditions: 


• UE_A, UE_B support 1 0Orel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UEA registered using user_3_priv@ims-a.net as per clause 4.2.3 

• UEB registered using user_3_priv@ims-b.net as per clause 4.2.3 

• UEA, UEB implicitly registered public identities include SIP and Tel URIs 

• UE_A, UE_B default public identity is a Tel_URI 




1 






Test sequence: 


Step 


J 


1 PR 


UE A is requested to send an instant message to "user 3 pub@ims-b.net' 








(CFWstepI) 




2 TB 


Verify that UE_B gets the message (CFW step 5) 


1 






Conformance 
criteria: 


Check 


1 


1 


TP_IMS_5097_09 in CFW step 3 (MESSAGE): 








ensure that { 








when { UE_A sends MESSAGE to UE_B 








not containing a P-Preferred-ldentity_header or 








containing a P-Preferred-ldentity_header 








indicating a Tel URI } 








then { IMS_B receives the MESSAGE 








containing a P-Asserted-ldentity_header 








indicating the defauit_registered_pubiic_identity of UEA 








and 








containing a P-Asserted-ldentity_header 








indicating a Tel derived SIP UR of UE A 1 








and 








UE B receives the MESSAGE} 
} 
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Test description 



TP_IMS_51 1 7_06 in CFW step 7 (200 OK): 
ensure that { 
when { DEB sends 2xx_response to UEA 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
indicating a Tel_URI of UE_B } 
then { IMS_A receives the 2xx_response 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity of UEB 
and 

containing a P-Asserted-ldentity_header 
indicating a Tel_derived_SIP_URI of UE_B 
and 

UE_A receives the 2xx_response } 
} 



The expected test body call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A sends an instant message 


2 






^ 










MESSAGE 


UE A sends MESSAGE to IMS A 


3 








■^ 








MESSAGE 


IMS A sends MESSAGE to IMS B 


4 










^ 






MESSAGE 


IMS B sends MESSAGE to UE B 


5 












■^ 






User B is informed about the instant message 


6 










<- 






200 OK 


UE B sends 200 OK to IMS B 


7 








<- 








200 OK 


IMS B sends 200 OK to IMS A 


8 






<- 










200 OK 


IMS A sends 200 OK to UE A 


9 




^ 














Optional: User A is presented a delivery report 
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4.5.2.1 .4 Standalone MESSAGE request with DNS/ENUM lookup procedures 



Test description 


Identifier: 


ID IMS 0005 


Summary: 


Standalone MESSAGE request with DNS/ENUM lookup procedures 


Configuration: 


CF M02-SS1-MT2C 


References 


Test purpose 


Specification reference 


IP IMS 5097 10 


TS 124 229 [1], clause 5.4.3.2, H 1 


Use Case: 


UC 13 1 




Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 1 0Orel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UEA registered using user_1_priv@ims-a.net as per clause 4.2.3 

• UEB registered using user_5_priv@ims-b.net as per clause 4.2.3 

• UE_A, UE_B registered public identities are SIP URIs only 

• DNS_B is configured with a DNS/ENUM entry mapping UE_B's E.I 64 number 
to user_5 SIP URI public identity 




Test sequence: 
1 


Step 




1 PR 


UE_A is requested to send an instant message addressed to the E.I 64 
number of user 5 configured in DNS B (CFW step 1) 


2 TB 


Verify that UE_B gets the message (CFW step 7) 


1 

Conformance 

criteria: 


Check 




1 


TP_IMS_5097_10 in CFW step 2 (MESSAGE): 
ensure that { 
when { UE_A sends MESSAGE to UE_B 
containing a Request_URI 
indicating a Tei_URi} 
then { IMS_A sends a DNS_Query to DNS_A 

containing the Tel_URi_E.164_Number } 
when { IMS_A receives DNS_Response 

containing a NAPTR Resource Record 
indicating the SIP URI of UE B} 
then { IMS_A sends the MESSAGE to IMS_B 
containing a Request_URI 
indicating a SIP_URI 
and 

UE B receives the MESSAGE} 
} 
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The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 




U U 
s E 
e A 
r 
A 


1 1 
M 1 
S i 

A 1 


3 
3 


1 
IVI 

s 

B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A sends an instant message 


2 






^ 










MESSAGE 


UE A sends IVIESSAGE to IMS A 


3 






■^ 










DNS QUERY 


IMS_A sends DNS QUERY to DNS, verify that 
the query contains an E.164 telephone URI 


4 






<- 










DNS RESPONSE 


DNS_A sends DNS RESPONSE containing a 
NAPTR resource record to IMS A 


5 






-> 










MESSAGE 


IMS_A sends MESSAGE to IMS_B, verify that 
the Request URI of the MESSAGE indicates a 
SIP URI 


6 






^ 








MESSAGE 


IMS B sends MESSAGE to UE B 


7 












^ 






User B is informed about the instant message 


8 










^ 






200 OK 


UE B sends 200 OK to IMS B 


9 






^ 










200 OK 


IMS B sends 200 OK to IMS A 


10 




< 


c. 










200 OK 


IMS A sends 200 OK to UE A 


11 




^ 














Optional: User A is presented a delivery report 



4.5.2.2 Initial INVITE dialog procedures 
4.5.2.2.1 Initial INVITE request procedure 



Test description | 


Identifier: 


ID IMS 0006 


Summary: 


Initial INVITE request procedures 


Configuration: 


OF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5046 01 


TS 1 24 229 [1 ], clause 5.2.6.3, If 4 


TP IMS 5097 01 


TS 124 229 [1], clause 5.4.3.2, H 1 


TP IMS 5097 02 


TS 124 229 [1], clause 5.4.3.2, H 1 


TP IMS 5107 02 


TS 124 229 [1], clause 5.4.3.2, H 49 


Use Case: 


UC 01 1 


1 




Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 1 0Orel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UEA registered using user_1_priv@ims-a.net as per clause 4.2.3 

• UE_B registered using user 1 priv@ims-b.net as per clause 4.2.3 

• UE A, UE B registered public identities are SIP URIs only 


Test sequence: 


Step 


■" ^^~ n 


1 TB 


Initiate an IMS VoIP call on UE A, addressed to "user 1 pub@ims- 
b.net"(CFWstep1) 


2P0 


Verify that UE B rings (CFW step 8) 


3P0 


Verify that ringback is present at UE A (CFW step 12) 


4P0 


Answer the call at UE B (CFW step 1 9) 


5P0 


Verify that voice can be exchanged in both directions (CFW step 27) 


6P0 


Release call at UE A (CFW step 28) 


7P0 


Verify that call is released at UE_B (CFW step 32) 


^~ " 




^"^^■r* 1 
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Test description 


Conformance 
criteria: 


Check 




1 


TP_IMS_5046_01 in CFW step 4 (INVITE): 
ensure that { 
when { UE A sends INVITE to UE B } 
then { IMS_B receives the INVITE 

containing an additional Via_header 
containing ( P-CSCF via port number and 
(P-CSCF-FQDN address or 
P-CSCF-IP_address)) of IMS_A and 
containing an additional Record-Route_header 
containing ( P-CSCF_port_number "where it awaits 
subsequent requests from the called party" and 
(P-CSCF-FQDN address or P-CSCF-IP address)) 
oflMS_A and 
not containing P-Preferred-ldentity_header and 
containing P-Asserted-ldentity_header 

containing an address of UFA and 
containing P-Charging- Vectorheader 
containing an icid_value_parameter 
and 

UE B receives INVITE 
} 
} 




2 


TP_IMS_5097_01 in CFW step 4 (INVITE): 
ensure that { 
when { UE_A sends an initial INVITE to UE_B} 
then { IMS_B receives the initial INVITE 

containing a P-Charging-Vector_header 
containing an icid_value_parameter 
and 

UE B receives the INVITE} 
} 




3 


TP_IMS_5097_02 in CFW step 4 (INVITE): 
ensure that { 
when { UE_A sends initial INVITE to UE_B} 
then { IMS_B receives the initial INVITE 

containing a topmost Record-Route_header 

indicating the originating S-CSCF_SIP_URI and 
containing a P-Charging-Vector_header 
(containing a orig-ioi_parameter 

indicating IMS_A and 
not containing a access-network-charging-info_parameter) 
and 

not containing a P-Access-Network-lnfo_header 
and 
UE B receives the INVITE) 

} 
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The expected test body call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A calls User B 


2 






-> 










INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UEA supports 


3 






^ 










100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


4 








-> 








INVITE 


IMS A S-CSCF forwards INVITE to IMS B 1- 
CSCF 


5 








^ 








100 Trying 


MSJB l-CSCF responds with a 100 Trying 
provisional response 


6 










^ 






INVITE 


IMS B P-CSCF forwards INVITE to UE B 


7 










^ 






100 Trying 


UE_B responds with a 100 Trying provisional 
response 


8 












^ 






User B is informed of incoming call of User A 



4.5.2.2.2 1xx provisional response to initial INVITE request procedures 



Test description 



Identifier: 



TD IIVIS 0007 



Ixx provisional response to initial INVITE request procedure 



Summary: 



Configuration: 



CF M02-SS1-MT2 



References 



Test purpose 



TP IMS 5055 01 



TP IMS 5115 01 



TP IMS 5131 01 



Specification reference 



TS 124 229 [1], clause 5.2.6.4, H 15 



TS 124 229 [1], clause 5.4.3.3, H 44 



TS 124 229 [1], clause 5.3.2.1, 1144 



Use Case: 



Pre-test 
conditions: 



UC 01 



Static configuration as per clause 4.3 

UE_A, UE_B support lOOrel, no SDP preconditions 

UE_A, UE_B have no filter criteria defined in HSS 

UE_A, UE_B IP bearers established as per clause 4.2.1 

UEA registered using user_1_priv@ims-a.net as per clause 4.2.3 

UE_B registered using user_1_priv@ims-b.net as per clause 4.2.3 

UE_A, UE_B registered public identities are SIP URIs only 



Test sequence: 



Step 



1 PR 



2 PR 



STB 



4P0 



5P0 



6P0 



7P0 



Initiate an IMS VoIP call on UE_A, 
(CFWstepI) 



addressed to "user_1_pub@ims-b.net" 



Verify that UE_B rings (CFW step 8) 



Verify that ringback is present at UE_A (CFW step 12) 



Answer the call at UE_B (CFW step 19) 



Verify that voice can be exchanged in both directions (CFW step 27) 



Release call at UE_A (CFW step 28) 



Verify that call Is released at UE_B (CFW step 32) 
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Test description 


Conformance 
criteria: 


Check 




1 


TP_IMS_5055_01 in CFW step 10 (180 Ringing): 
ensure that { 
when { UEB sends a Ixxresponse to UE_A } 
then { IMS_A receives 1xx_response 

containing Record-Route_header 
containing the P-CSCF_port_number of IMS_B 'where it 
expects 

subsequent requests' and 
not containing comp_parameter and 
not containing P-Preferred-ldentity_header and 
containing P-Asserted-ldentity_header 
indicating the address "sent in P-Called_Party-ID header 

of the initial request" 
and 

UE A receives 1xx response 
} 
} 




2 


TP_II\/IS_5115_01 in CI=W step 10 (180 Ringing): 
ensure that { 
when { UEB sends Ixxresponse to UEA } 
then { ll\/IS_A receives the Ixxresponse 

containing a P-Charging-Vector_header 
containing a orig-ioi_parameter 

indicating IMS_A and 
containing a term-ioi_parameter 
indicating IMS_B 
and 

UE A receives the 1xx response } 
} 




3 


TP_IMS_5131_01 in CFW step 10 (180 Ringing): 
ensure that { 
when { UEB sends Ixxresponse to UEA } 
then { ll\/IS_A receives the 1xx_response 

not containing a P-Charging-Function-Addresses_header 
and 

UE A receives the 1xx response } 
} 



The expected test body call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






8 












^ 






User B is informed of incoming call of User A 


9 










<- 






180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 


10 








«- 








180 Ringing 


IMS B S-CSCF forwards 180 Ringing response 
to IMS A S-CSCF 


11 






«- 










180 Ringing 


IMS_A P-CSCF forwards the 180 Ringing 
response to UEA 


12 




^ 














User A is informed that UE B is ringing 
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4.5.2.2.3 2xx final response and ACK for initial INVITE request procedures 



Test description 


Identifier: 


ID IMS 0008 


Summary: 


2xx final response and ACK for initial INVITE request procedures 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5055 02 


TS 124 229 [1], clause 5.2.6.4, H 15 


TP IMS 5115 02 


TS 124 229 [1], clause 5.4.3.3, H 44 


TP IMS 5131 02 


TS 1 24 229 [1 ], clause 5.3.2. 1 , H 44 


TP IMS 5107 03 


TS 124 229 [1], clause 5.4.3.2, H 49 


Use Case: 


UC 01 1 


1 1 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 1 0Orel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UEA registered using user_1_priv@ims-a.net as per clause 4.2.3 

• UEB registered using user_1_priv@ims-b.net as per clause 4.2.3 

• UE A, UE B registered public identities are SIP URIs only 


1 


i 


Test sequence: 


step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to "user 1 pub@ims-b.net" 
(CFWstepI) 


2 PR 


Verify that UEB rings (CFW step 8) 


3 PR 


Verify that ringback is present at UE A (CFW step 12) 


4 TB 


Answer the call at UE_B (CFW step 19) 


5P0 


Verify that voice can be exchanged in both directions (CFW step 27) 


6P0 


Release call at UE A (CFW step 28) 


7P0 


Verify that call is released at UE B (CFW step 32) 




Conformance 
criteria: 


Check 


^^ 


1 


TP_IMS_5055_02 in CFW step 21 (200 Ok): 
ensure that { 
when { UEB sends a 2xx_response to UE_A } 
then { IMS_A receives 2xx_response 

containing Record-Route_header 
containing the P-CSCF_port_number of IMS_B 'where it 
expects subsequent requests' and 

not containing comp_parameter and 
not containing P-Preferred-ldentity_header and 
containing P-Asserted-ldentity_header 
indicating the address "sent in P-Called_Party-ID header of the 
initial request" 
and 

UE B receives 2xx response 
} 
} 




2 


TP_IMS_51 1 5_02 in CFW step 21 (200 Ok): 
ensure that { 
when { UEB sends 2xx_response to UEA } 
then { ll\/IS_A receives the 2xx_response 

containing a P-Charging-Vector_header 
containing an orig-ioi_parameter 

indicating lt\/IS_A and 
containing a term-ioi_parameter 
indicating lt\/IS_B 
and 
UE A receives the 2xx response } 

} 
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Test description 




3 


TP_IMS_5131_02 in CFW step 21 (200 Ok): 
ensure that { 
when { UEB sends 2xx_response to UEA } 
then { IMS_A receives the 2xx_response 

not containing a P-Charging-Function-Addresses_header 
and 

UE A receives the 2xx response } 
} 




4 


TP_IMS_5107_03 in CFW step 25 (ACK): 
ensure that { 
when { UE_A sends ACK to UE_B } 
then { mS_B receives the ACK 

(containing a P-Charging-Vector_header 

not containing a access-networl<-charging-info_parameter 
or 

not containing a P-Charging-Vector_header ) 
and 

not containing a P-Access-Networl<-lnfo__header 
and 

UE B receives the ACK} 
} 



The expected test body call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






12 




^ 














User A is informed that UE B is ringing 


13 






^ 










PRACK 


UE_A acl<nowledges the receipt of 180 response by 
sending PRACK 


14 








■^ 








PRACK 


IMS A S-CSCF forwards PRACK to IMS B 
S-CSCF 


15 










-» 






PRACK 


IMS B P-CSCF forwards PRACK to UE B 


16 










<- 






200 OK 


UE B responds PRACK with 200 OK 


17 








^ 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


18 






<r 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


19 












^ 






User B answers call 


20 










<- 






200 OK 


UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 


21 








<- 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


22 






<r 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


23 




4r 














User A is presented that call in process 


24 






^ 










ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


25 








^ 








ACK 


IMS A S-CSCF forwards ACK to IMS B S-CSCF 


26 










■^ 






ACK 


IMS B P-CSCF forwards ACK to UE B 


27 












■^ 






User B is informed that the call is in progress 
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4.5.2.2.4 Initial INVITE request procedure with implicit Tel URI 



Test description 


Identifier: 


ID IMS 0009 


Summary: 


Initial INVITE request procedure with implicit Tel URI 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5097 03 


TS 124 229 [1], clause 5.4.3.2, H 1 


Use Case: 


UC 01 1 




Pre-test 


• Static configuration as per clause 4.3 


conditions: 


• UE_A, UE_B support 1 0Orel, no SDP preconditions 




• UE A, UE B have no filter criteria defined in HSS 




• UE A, UE B IP bearers established as per clause 4.2.1 




• UEA registered using user_2_priv@ims-a.net as per clause 4.2.3 




• UEB registered using user_2_priv@ims-b.net as per clause 4.2.3 




• UE_A, UE_B implicitly registered public identities include SIP and Tel URIs 




UE_A, UE_B default public identity is a SIP_URI 


^^^^^^^^^^1 




Test sequence: 


Step 




1 TB 


Initiate an IMS VoIP call on UE A, addressed to "user 2 pub@ims- 






b.net"(CFWstep1) 


2P0 


Verify that UEB rings (CFW step 8) 


3P0 


Verify that ringback is present at UE A (CFW step 12) 


4P0 


Answer the call at UE B (CFW step 1 9) 


5P0 


Verify that voice can be exchanged in both directions (CFW step 27) 


6P0 


Release call at UE A (CFW step 28) 


7P0 


Verify that call is released at UE_B (CFW step 32) 






Conformance 
criteria: 


Clieck 




1 


TP_IMS_5097_03 in CFW step 4 (INVITE): 






ensure that { 






when { UE A sends initial INVITE to UE B 






not containing a P-Preferred-ldentity_header or 






containing a P-Preferred-ldentity_header 






not indicating a Tel_URI} 






then { IMS B receives the initial INVITE 






containing a P-Asserted-ldentity_header 






indicating the default_registered_public_identity of UEA 






and 






containing a P-Asserted-ldentity_header 






indicating a Tel URI of UE A 






and 






UE B receives the INVITE} 
} 
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The expected test body call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




-» 














User A calls User B 


2 






^ 










INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE A supports 


3 






4- 










100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


4 








^ 








INVITE 


IMS A S-CSCF forwards INVITE to IMS B 1- 
CSCF 


5 








«- 








100 Trying 


ll\/IS_B l-CSCF responds with a 100 Trying 
provisional response 


6 










-> 






INVITE 


IMS B P-CSCF forwards INVITE to UE B 


7 










^ 






100 Trying 


UE_B responds with a 100 Trying provisional 
response 


8 












^ 






User B is informed of incoming call of User A 
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4.5.2.2.5 1xx provisional response to initial INVITE request procedures with implicit Tel URI 



Test description 


Identifier: 


ID IMS 0010 


Summary: 


1xx provisional response to initial INVITE request procedures with implicit Tel URI 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5115 03 


TS 124 229 [1], clause 5.4.3.3, H 44 


Use Case: 


UC 01 1 




Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 1 0Orel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UEA registered using user_2_priv@ims-a.net as per clause 4.2.3 

• UEB registered using user_2_priv@ims-b.net as per clause 4.2.3 

• UE_A, UE_B implicitly registered public identities include SIP and Tel URIs 
UE A, UE B default public identity is a SIP URI 


^^^^^^^^^^^ 




Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to "user 2 pub@ims-b.net" 
(CFWstepI) 


2 PR 


Verify that UEB rings (CFW step 8) 


STB 


Verify that ringbacl< is present at UE_A (CFW step 12) 


4P0 


Answer the call at UE B (CFW step 19) 


5P0 


Verify that voice can be exchanged in both directions (CFW step 27) 


6P0 


Release call at UE A (CFW step 28) 


7P0 


Verify that call is released at UE_B (CFW step 32) 






Conformance 
criteria: 


Clieck 




1 


TP_IMS_5115_03 in CFW step 10 (180 Ringing): 
ensure that { 
when { UEB sends Ixxresponse to UEA 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
indicating a SIP_URI} 
then { IMS_A receives the Ixxresponse 

containing a P-Asserted-ldentity_header 

indicating the defauit_registered_pubiic_identity of UEB 
and 

containing a P-Asserted-ldentity_header 
indicating a Tel_URI of UE_B 
and 

UE A receives the 1xx response } 
} 



The expected test body call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


U 
s 
e 
r 
B 






8 












^ 






User B is informed of incoming call of User A 


9 










<r 






180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 


10 








<r 








180 Ringing 


IMS B S-CSCF forwards 180 Ringing response 
to IMS A S-CSCF 


11 






^ 










180 Ringing 


IMS_A P-CSCF forwards the 180 Ringing 
response to UEA 


12 




^ 














User A is informed that UE B is ringing 
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4.5.2.2.6 2xx final response to initial INVITE request procedures with implicit Tel URI 



Test description 


Identifier: 


ID IMS 0011 


Summary: 


2xx final response to initial INVITE request procedures with implicit Tel URI 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5115 04 


TS 124 229 [1], clause 5.4.3.3, H 44 


Use Case: 


UC 01 1 




Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 1 0Orel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UEA registered using user_2_priv@ims-a.net as per clause 4.2.3 

• UEB registered using user_2_priv@ims-b.net as per clause 4.2.3 

• UE_A, UE_B implicitly registered public identities include SIP and Tel URIs 
UE A, UE B default public identity is a SIP URI 


^^^^^^^^^^^ 




Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to "user 2 pub@ims-b.net" 
(CFWstepI) 


2 PR 


Verify that UE B rings (CFW step ) 


3 PR 


Verify that ringback is present at UE A (CFW step 1e) 


4 TB 


Answer the call at UE_B (CFW step 19) 


5P0 


Verify that voice can be exchanged in both directions (CFW step 27) 


6P0 


Release call at UE A (CFW step 28) 


7P0 


Verify that call is released at UE_B (CFW step 32) 






Conformance 
criteria: 


Clieck 




1 


TP_IMS_51 1 5_04 in CFW step 21 (200 Ok): 
ensure that { 
when { UEB sends 2xx_response to UEA 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
not indicating a Tel_URI} 
then { IMS_A receives the 2xx_response 

containing a P-Asserted-ldentity_header 

indicating the defauit_registered_pubiic_identity of UEB 
and 

containing a P-Asserted-ldentity_header 
indicating a Tel_URI of UE_B 
and 

UE A receives the 2xx response } 
} 



The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


\ 

M 
S 
B 


u 

E 
B 


U 
s 
e 
r 
B 






19 












^ 






User B answers call 


20 










<r 






200 OK 


UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 


21 








<r 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


22 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


23 




^ 














User A is presented that call in process 
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4.5.2.2.7 Initial INVITE request procedure with implicit SIP URI 



Test description 


Identifier: 


ID IMS 0012 


Summary: 


Initial INVITE request procedure with implicit SIP URI 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5097 04 


TS 124 229 [1], clause 5.4.3.2, H 1 


Use Case: 


UC 01 1 




Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 1 0Orel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UEA registered using user_3_priv@ims-a.net as per clause 4.2.3 

• UEB registered using user_3_priv@ims-b.net as per clause 4.2.3 

• UE_A, UE_B implicitly registered public identities include SIP and Tel URIs 
UE A, UE B default public identity is a Tel URI 


^^^^^^^^^^1 




Test sequence: 


Step 




1 TB 


Initiate an IMS VoIP call on UE A, addressed to UE B's TEL URI 
(CFWstepI) 


2P0 


Verify that UEB rings (CFW step 8) 


3P0 


Verify that ringback is present at UE A (CFW step 12) 


4P0 


Answer the call at UE B (CFW step 1 9) 


5P0 


Verify that voice can be exchanged in both directions (CFW step 27) 


6P0 


Release call at UE A (CFW step 28) 


7P0 


Verify that call is released at UE_B (CFW step 32) 






Conformance 
criteria: 


Clieck 




1 


TP_IMS_5097_04 in CFW step 4 (INVITE): 
ensure that { 
when { UE_A sends initial INVITE to UE_B 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
indicating a Tel_URI } 
then { IMS_B receives the initial INVITE 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity of UEA 
and 

containing a P-Asserted-ldentity_header 
indicating a Tel_derived_SIP_URI of UE_A 
and 

UE B receives the INVITE} 
} 
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The expected test body call flow sequence is: 





U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A calls User B 


2 






^ 










INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE A supports 


3 






^ 










100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


4 








^ 








INVITE 


IMS A S-CSCF forwards INVITE to IIMS B 1- 
CSCF 


5 








^ 








100 Trying 


ll\/IS_B l-CSCF responds with a 100 Trying 
provisional response 


6 










-> 






INVITE 


IMS B P-CSCF forwards INVITE to UE B 


7 










^ 






100 Trying 


UE_B responds with a 100 Trying provisional 
response 


8 












■^ 






User B is informed of incoming call of User A 



£75/ 



55 



ETSI TS 186 011-2 VI. 1.1 (2009-03) 



4.5.2.2.8 1xx provisional response to initial INVITE request procedures with implicit SIP URI 



Test description 


Identifier: 


ID IMS 0013 


Summary: 


1xx provisional response to initial INVITE request procedures with implicit SIP URI 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5115 05 


TS 124 229 [1], clause 5.4.3.3, H 44 


Use Case: 


UC 01 1 




Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 1 0Orel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UEA registered using user_3_priv@ims-a.net as per clause 4.2.3 

• UEB registered using user_3_priv@ims-b.net as per clause 4.2.3 

• UE_A, UE_B implicitly registered public identities include SIP and Tel URIs 
UE A, UE B default public identity is a Tel URI 


^^^^^^^^^^^ 




Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to UE B's TEL URI 
(CFWstepI) 


2 PR 


Verify that UEB rings (CFW step 8) 


STB 


Verify that ringbacl< is present at UE_A (CFW step 12) 


4P0 


Answer the call at UE B (CFW step 19) 


5P0 


Verify that voice can be exchanged in both directions (CFW step 27) 


6P0 


Release call at UE A (CFW step 28) 


7P0 


Verify that call is released at UE_B (CFW step 32) 






Conformance 
criteria: 


Clieck 




1 


TP_IMS_5115_05 in CFW step 10 (180 Ringing): 
ensure that { 
when { UEB sends Ixxresponse to UEA 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
indicating a Tel_URI } 
then { IMS_A receives the Ixxresponse 

containing a P-Asserted-ldentity_header 

indicating the defauit_registered_pubiic_identity of UEB 
and 

containing a P-Asserted-ldentity_header of UEB 
indicating a Tel_derived_SIP_URI 
and 

UE A receives the 1xx response } 
} 
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The expected test body call flow sequence is: 





U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A calls User B 


2 






^ 










INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


3 






^ 










100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


4 








-^ 








INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


5 








«- 








100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


6 










^ 






INVITE 


IMS B P-CSCF forwards INVITE to UE B 


7 










^ 






100 Trying 


UE_B responds with a 100 Trying provisional 
response 


8 












^ 






User B is informed of incoming call of User A 


9 










^ 






180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 


10 








<r 








180 Ringing 


IMS B S-CSCF forwards 180 Ringing response 
to IMS A S-CSCF 


11 






<- 










180 Ringing 


IMS_A P-CSCF forwards the 180 Ringing 
response to UE A 


12 




^ 














User A is informed that UE B is ringing 
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4.5.2.2.9 2xx final response to initial INVITE request procedures with implicit SIP URI 



Test description 


Identifier: 


ID IMS 0014 


Summary: 


2xx final response to initial INVITE request procedures with implicit SIP URI 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5115 06 


TS 124 229 [1], clause 5.4.3.3, H 44 


Use Case: 


UC 01 1 




Pre-test 




Static configuration as per clause 4.3 


conditions: 




UE_A, UE_B support lOOrel, no SDP preconditions 

UE_A, UE_B have no filter criteria defined in HSS 

UE_A, UE_B IP bearers established as per clause 4.2.1 

UEA registered using user_3_priv@ims-a.net as per clause 4.2.3 

UEB registered using user_3_priv@ims-b.net as per clause 4.2.3 

UE_A, UE_B implicitly registered public identities include SIP and Tel URIs 

UE A, UE B default public identity is a Tel URI 


^^^^^^^^^^^ 




Test sequence: 


Step 




1 PR 




Initiate an IMS VoIP call on UE A, addressed to UE B's TEL URI (CFW 








step 1 ) 


2 PR 


Verify that UEB rings (Cl^ step 8) 


3 PR 


Verify that ringback is present at UE A (CFW step 12) 


4 TB 


Answer the call at UE_B (CFW step 19) 


5P0 


Verify that voice can be exchanged in both directions (CFW step 27) 


6P0 


Release call at UE A (CFW step 28) 


7P0 


Verify that call is released at UE_B (CFW step 32) 






Conformance 
criteria: 


Clieck 




1 




TP_IMS_51 1 5_06 in CFW step 21 (200 Ok): 








ensure that { 








when { UEB sends 2xx_response to UEA 








not containing a P-Preferred-ldentity_header or 








containing a P-Preferred-ldentity_header 








indicating a Tel_URI } 








then { IMS_A receives the 2xx_response 








containing a P-Asserted-ldentity_header 








indicating the defauit_registered_pubiic_identity of UEB 








and 








containing a P-Asserted-ldentity_header 








indicating a Tel derived SIP URI of UE B 








and 








UE A receives the 2xx response } 
} 
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The expected test body call flow sequence is: 





U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






12 




^ 














User A is informed tliat UE B is ringing 


13 






^ 










PRACK 


UE_A acl<nowledges the receipt of 180 response by 
sending PRACK 


14 








■^ 








PRACK 


IMS A S-CSCF forwards PRACK to IMS B 
S-CSCF 


15 










^ 






PRACK 


IMS B P-CSCF forwards PRACK to UE B 


16 










<- 






200 OK 


UE_B responds PRACK with 200 OK 


17 








<- 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


18 






<- 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


19 












«- 






User B answers call 
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4.5.2.2.10 Initial INVITE request with DNS/ENUM lookup procedures 



Test description 


Identifier: 


ID IMS 0015 


Summary: 


Initial INVITE request with DNS/ENUM lookup procedures 


Configuration: 


CF M02-SS1-MT2C 


References 


Test purpose 


Specification reference 


IP IMS 5097 05 


TS 124 229 [1], clause 5.4.3.2, H 1 


Use Case: 


UC 01 1 




Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 1 0Orel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UEA registered using user_1_priv@ims-a.net as per clause 4.2.3 

• UEB registered using user_5_priv@ims-b.net as per clause 4.2.3 

• UE_A, UE_B registered public identities are SIP URIs only 

• DNS_B is configured with a DNS/ENUM entry mapping UE_B's E.I 64 number 
to "user_5_pub@ims-b.net" 




Test sequence: 


Step 




1 TB 


Initiate an IMS VoIP call on UE_A, addressed to the E.I 64 number 

configured in DNS B (CFW step 1) 

(CFWstepI) 


2 TB 


Verify that UE_B rings (CFW step 8) 


3P0 


Verify that ringback is present at UE A (CFW step 12) 


4P0 


Answer the call at UE B (CFW step 1 9) 


5P0 


Verify that voice can be exchanged in both directions (CFW step 27) 


6P0 


Release call at UE A (CFW step 28) 


7P0 


Verify that call is released at UE B (CFW step 32) 




— 1 


Conformance 
criteria: 


Cliecit 




1 


TP_IMS_5097_05 in CFW step 4 (INVITE): 
ensure that { 
when { UE_A sends initial INVITE to UE_B 
containing a Request_URI 
indicating a Tel URI} 
then { IMS_A sends a DNS_Query to DNS_A 

containing the Tel_URI_E.164_Number } 
when { IMS_A receives DNS_Response 

containing a NAPTR Resource Record 
indicating the SIP URI of UE Bj 
then { IMS_A sends the initial INVITE to IMS_B 
containing a Request_URI 
indicating a SIP_URI 
and 
UE B receives the INVITE} 

} 
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The expected test body call flow sequence is: 



Step Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


D 
N 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A calls User B 


2 






^ 










INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UEA supports 


3 






^ 










1 00 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


4 








-^ 








DNS QUERY 


IMS_A sends DNS QUERY to DNS_A containing 
a E.I 64 telephone URI 


5 








<r 








DNS RESPONSE 


DNS_A send a DNS RESPONSE to IMS_A 
containing a NAPTR resource record 


6 








■^ 






INVITE 


IMS A S-CSCF forwards INVITE to IMS B 1- 
CSCF 


7 








^ 






100 Trying 


IIV1S_B l-CSCF responds with a 100 Trying 
provisional response 


10 












> 




INVITE 


IMS B P-CSCF forwards INVITE to UE B 


11 










< 


~ 




100 Trying 


UE_B responds with a 100 Trying provisional 
response 


12 












^ 






User B is informed of incoming call of User A 
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4.5.2.3 Special case of initial INVITE dialog procedures 

4.5.2.3.1 P-CSCF initiated session release, session establishment cancelled 



Test description 


Identifier: 


ID IMS 0016 


Summary: 


P-CSCF-initiated session release, session establishment cancelled, resources no 
longer available 


Configuration: 


OF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


IP IMS 5072 01 


TS 124 229 [1] clause 5.2.8.1 .1 , If 1 


Use Case: 


UC 10(CFW for Cancelled) | 




Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 1 0Orel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UE_A registered using user_1_priv@ims-a.net as per clause 4.2.3 

• UEB registered using user_1_priv@ims-b.net as per clause 4.2.3 

• UE_A, UE_B registered public identities are SIP URIs only 

• P-CSCF can receive notifications of UE A network access failures 






Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to "user 1 pub@ims-b.net" 
(CFWstepI) 


2 PR 


Verify that UEB rings (CFW step 8) 


3 PR 


Verify that ringback is present at UE A (CFW step 12) 


4 TB 


Remove cable, antenna or battery from UE_A (CFW step 19) 


STB 


Verify that call is ended at UE B (CFW step 25) 


^B 




Conformance 
criteria: 


Clieck 




1 


TP_IMS_5072_01 in CFW step 20 (CANCEL): 
ensure that { 
when { IMS A receives "an indication that UE A is no ionger available" } 
then { IMS A sends a CANCEL to IMS B and 
UE B receives the CANCEL 
} 
} 



The expected test body call flow is: 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


U 
s 
e 
r 
B 






19 
















LOSS 


Internal a message that resources for UEA are not 
available 


20 








^ 








CANCEL 


IMS A sends CANCEL to IMS B 


22 








<r 








200 OK 


IMS B S-CSCF responds with a 200 OK 


23 










-» 






CANCEL 


IMS B sends CANCEL to UE B 


24 










<r 






200 OK 


UE B responds with 200 OK 


25 












^ 






User B is informed the call has ended 
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4.5.2.3.2 P-CSCF initiated session release, session released from originating network 



Test description 


Identifier: 


ID IMS 0017 


Summary: 


P-CSCF-initiated session release, session released from originating network 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


IP IMS 5073 01 


TS 124 229 [1], clause 5.2.8.1.2, HI 


Use Case: 


UC 1 


1 (CFW for originating network) 




Pre-test 




Static configuration as per clause 4.3 


conditions: 




UE_A, UE_B support lOOrel, no SDP preconditions 

UE_A, UE_B have no filter criteria defined in HSS 

UE_A, UE_B IP bearers established as per clause 4.2.1 

UEA registered using user_1_priv@ims-a.net as per clause 4.2.3 

UEB registered using user_1_priv@ims-b.net as per clause 4.2.3 

UE_A, UE_B registered public identities are SIP URIs only 

P-CSCF can receive notifications of UE A network access failures 


^^^^^^^^^^^ 




Test sequence: 


Step 




1 PR 




Initiate an IMS VoIP call on UE A, addressed "user 1 pub@ims-b.net" 








(CFW step 1) 


2 PR 


Verify that UEB rings (CFW step 8) 


3 PR 


Verify that ringback is present at UE A (CFW step 12) 


4 PR 


Answer the call at UE B (CFW step 1 9) 


5 PR 


Verify that voice can be exchanged in both directions (CFW step 27) 


6 TB 


Remove cable, antenna or battery from UE A (CFW step 28) 


7 TB 


Verify that call is released at UE B (CFW step 31) 






Conformance 
criteria: 


Clieck 




1 




TP_IMS_5073_01 in CFW step 29 (BYE): 








ensure that { 








when { UEA is no_longer_available } 








then { IMS_B receives BYE from IMS_A 








containing Request_URI 








indicating the Contact_header_value of UEB and 








containing To_header 








indicating the initiai 200 OK To header value from UE B 








containing From_header 








indicating the initiai INVITE_From_header_value from UEA 








and 








containing Call-IDheader 








indicating the initiai INVITE Call Id header value from UE A 








and 








containing CSeq_header 








indicating an incremented Sequence_Number and 








containing Route_header 








indicating 'dialog specific routing information for UEB' and 








"further headers based on local policy or call release reason" 








and 








UE B receives BYE 
} 
} 
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The expected test body call flow is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






28 
















LOSS 


PDF or SPDF sends a message that resources are 
missing for UE A 


29 








^ 








BYE 


IMS A P-CSCF sends BYE to IIVIS B 
S-CSCF 


30 










^ 






BYE 


IMS B P-CSCF forwards BYE to UE B 


31 












^ 






User B is informed the call has ended 
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4.5.2.3.3 P-CSCF initiated session release, session released from terminating network 



Test description 


Identifier: 


ID IMS 0018 


Summary: 


P-CSCF-initiated session release, session released from terminating network 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


IP IMS 5074 01 


TS 1 24 229 [1], clause 5.2.8.1 .2, H 1 


Use Case: 


UC_1 2 (CFW for terminating network) | 




Pre-test 




Static configuration as per clause 4.3 


conditions: 




UE_A, UE_B support lOOrel, no SDP preconditions 

UE_A, UE_B have no filter criteria defined in HSS 

UE_A, UE_B IP bearers established as per clause 4.2.1 

UEA registered using user_1_priv@ims-a.net as per clause 4.2.3 

UEB registered using user_1_priv@ims-b.net as per clause 4.2.3 

UE_A, UE_B registered public identities are SIP URIs only 

P-CSCF can receive notifications of UE B network access failures 


^^^^^^^^^^^ 




Test sequence: 


Step 




1 PR 




Initiate an IMS VoIP call on UE A, addressed to "user 1 pub@ims-b.net" 








(CFW step 1) 


2 PR 


Verify that UEB rings (CFW step 8) 


3 PR 


Verify that ringback is present at UE A (CFW step 12) 


4 PR 


Answer the call at UE B (CFW step 1 9) 


5 PR 


Verify that voice can be exchanged in both directions (CFW step 27) 


6 TB 


Remove cable, antenna or battery from UE B (CFW step 28) 


7 TB 


Verify that call is released at UE A (CFW step 31) 






Conformance 
criteria: 


Clieck 




1 




TP_IMS_5074_01 in CFW step 29 (BYE): 








ensure that { 








when { UEB is no_longer_available } 








then { IMS_A receives BYE from IMS_B 








containing Request_URI 








indicating the Contact_header_value of UEA and 








containing To_header 








indicating the initiai INVITE To header value from UE A 








containing From_header 








indicating the initial 200 OK From header value from UE B 








and 








containing Call-IDheader 








indicating the initial INVITE Call Id header value from UE A 








and 








containing CSeq_header 








indicating an incremented Sequence_Number and 








containing Route_header 








indicating 'dialog specific routing information for UEA ' and 








"further headers based on local policy or call release reason" 








and 








UE A receives BYE 
} 
} 
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The expected test body call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






28 
















LOSS 


PDF or SPDF(in IMS_B) sends a message that 
resources are missing for UE B 


29 








<- 








BYE 


IMS B P-CSCF sends BYE to IIVIS A 
S-CSCF 


30 






<- 










BYE 


IMS A P-CSCF forwards BYE to UE A 


31 




<r 














User A is informed the call has ended 



4.5.2.3.4 Initial request to non-existent user procedures 



Test description 


Identifier: 


ID IMS 0019 


Summary: 


Initial INVITE request to non-existent user procedures 


Configuration: 


CF M02-SS1 


References 


Test purpose 


Specification reference 


TP IMS 5132 01 


TS 124 229 [1], clause 5.3.2.1, 1132 


Use Case: 


UC_05 1 


r 




1 


Pre-test 


• Static configuration as per clause 4.3 




conditions: 


• UEA support lOOrel, no SDP preconditions 

• UE_A have no filter criteria defined in HSS 

• UEA IP bearers established as per clause 4.2.1 

• UEA registered using user_1_priv@ims-a.net as per clause 4.2.3 

• UE A registered public identities are SIP URIs only 




L 






Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to 








sip:non existent user@ims-b.net (CFW step 1) 




2 TB 


Verify that an error is received and call is aborted at UE_A (after CFW 








step 6) 


T 


Conformance 
criteria: 


Check 




J 


1 


TP_IMS_5132_01 in CFW step 6 (404 or 604 Response): 






ensure that { 








when { UE_A sends INVITE 








containing a Request_URI 








indicating a non existing user in IMS B} 








then { IMS B receives the INVITE 








and 








IMS_B sends (a 404_response or a 604_response) 








and 








UE A receives the response } 
} 
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The expected test body call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A calls User B 


2 






-> 










INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UEA supports 


3 






^ 










100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


4 








-> 








INVITE 


IMS A S-CSCF forwards INVITE to IMS B 1- 
CSCF 


5 








^ 








100 Trying 


MSJB l-CSCF responds with a 100 Trying 
provisional response 


6 








«- 








404 Not Found or 

604 Does not exist anywhere 


IMS_B l-CSCF generates error message 
indicating non-existent user 


7 






<- 










404 Not Found or 

604 Does not exist anywhere 


IMS_A P-CSCF forwards error response to UE_A 


8 




^ 














User A is informed of "no such user" 



4.5.2.3.5 Initial request to non-registered user with no filter criterion 



Test description | 


Identifier: 


TD IMS 0020 


Summary: 


Initial request to non-registered user with no filter criterion 


Configuration: 


CF M02-SS1-MT2b 


References 


Test purpose 


Specification reference 


TP IMS 5133 01 


TS 124 229 [1], clause 5.3.2.1, 1133 


Use Case: 


UC 03 1 




Pre-test 


• Static configuration as per clause 4.3 


conditions: 


• UE_A, UE_B support 1 0Orel, no SDP preconditions 




• UE A, UE B have no filter criteria defined in HSS 




• UE A, UE B IP bearers established as per clause 4.2.1 




• UEA registered using user_1_priv@ims-a.net as per clause 4.2.3 




• UE_B not registered as user_1_priv@ims-b.net 




• UEA registered public identities are SIP URIs only 


L 




Test sequence: 


Step 


- 


1 TB 


Initiate an IMS VoIP call on UE A, addressed to "user 1 pub@ims-b.net" 






(CFWstepI) 


2 TB 


Verify that error is received and call is aborted at UE A (CFW step 8) 


I 


1 


Conformance 
criteria: 


Check 


1 


1 


TP_IMS_5133_01 in CFW step 6 (480 Response): 






ensure that { 






when { UE A sends INVITE to UE B } 






then { IMS B receives the INVITE and 






sends a 480 response to IMS A 






and 






UE A receives the 480 response } 
} 



ETSI 



67 



ETSI TS 186 011-2 VI. 1.1 (2009-03) 



The expected test body call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




^ 














User A calls User B 


2 






-> 










INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UEA supports 


3 






^ 










100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


4 








-> 








INVITE 


IMS A S-CSCF forwards INVITE to IMS B 1- 
CSCF 


5 








^ 








100 Trying 


MSJB l-CSCF responds with a 100 Trying 
provisional response 


6 








<- 








480 Temporarily unavailable 


IMS_B l-CSCF generates error message 
indicating unavailable user 


7 






<r 










480 Temporarily unavailable 


IMS_A P-CSCF forwards error response to UE_A 


8 




^ 














User A is informed of User B unreachable 



4.5.2.3.6 Initial request to non-registered user with terminating unregistered filter criterion 



Test description 



Identifier: 



TD IIVIS 0021 



Initial request to non-registered user with terminating unregistered filter criterion 



Summary: 



Configuration: 



CF M02-SS1-MT2-AST4b 



References 



Test purpose 



TP IMS 5109 01 



Specification reference 



TS 124 229 [1], clause 5.4.3.3, H 35 



Use Case: 

I ■ 

Pre-test 
conditions: 



UC 04 



Static configuration as per clause 4.3 

UE_A, UE_B support lOOrel, no SDP preconditions 

UE_A has no filter criteria defined in HSS 

IMS_B has terminating unregistered criterion set for UE_B on INVITE indicating 

SESSION_TERMINATED option and forward the INVITE to AS_B 

AS_B is unreachable from IIVIS_B 

UE_A, UE_B IP bearers established as per clause 4.2.1 

UEA registered using user_1_priv@ims-a.net as per clause 4.2.3 

UE_B not registered as user_4_priv@ims-b.net 

UE_A registered public identities are SIP URIs only 



Test sequence: 



Step 



1 PR 



2 TB 



Initiate an IIVIS VoIP call on UE_A, addressed to "user_4_pub@ims-b.net" 
(CFWstepI) 



Verify that error is received and call is aborted at UEA (CFW step 6 
and 8) 



Conformance 
criteria: 



Check 



1 



TP_II\/IS_5109_01 in CFW step 6 (Error Response): 
ensure that { 
when { UE_A sends INVITE to UE_B } 
then { IMS_B receives the INVITE and 

sends (a 408_response or a 5xx_response) to IMS_A 
and 
UEA receives the response } 
I 
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The expected test body call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




-» 














User A calls User B 


2 






^ 










INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE A supports 


3 






4- 










100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


4 








^ 








INVITE 


IMS A S-CSCF forwards INVITE to IMS B 1- 
CSCF 


5 








«- 








100 Trying 


ll\/IS_B l-CSCF responds with a 100 Trying 
provisional response 


6 








<- 








408 Request Timeout or 
5xx Response 


IMS_B l-CSCF forwards S-CSCF error message 
indicating unreachable AS 


7 






<- 










408 Request Timeout or 
5xx Response 


IMS_A P-CSCF forwards error response to UE_A 


8 




^ 














User A is informed of "not reachable" 
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4.5.2.3.7 S-CSCF initiated session release from originating network 



Test description 


Identifier: 


ID IMS 0022 


Summary: 


S-CSCF-initiated release of established session from originating network 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


IP IMS 5139 01 


TS 124 229 [1], clause 5.4.5.1.2, HI 


Use Case: 


UC_08 (CFW for originating network) | 


^^^^^^_ 






Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 1 0Orel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined In HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UEA registered using user_1_prlv@lms-a.net as per clause 4.2.3 

• UEB registered using user_1_prlv@lms-b.net as per clause 4.2.3 

• UE A, UE B registered public Identities are SIP URIs only 


L 






Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to "user 1 pub@lms-b.net" 
(CFW step 1) 


2 PR 


Verify that UEB rings (CFW step 8) 


3 PR 


Verify that ringback Is present at UE A (CFW step 12) 


4 PR 


Answer the call at UE B (CFW step 1 9) 


5 PR 


Verify that voice can be exchanged In both directions (CFW step 27) 


6 TB 


Set UE A registration status to de-registered In IMS A HSS 
(CFW step 28) 


7 TB 


Verify that call is ended at UE_B (CFW step 30) 


8P0 


Verify that call Is ended at UE A (CFW step 34) 


9P0 


Verify that UE A Is dereglstered 




Conformance 
criteria: 


Check 




1 




TP_IMS_5139_01 in CFW step 28 (BYE): 
ensure that { 
when { IMS A receives 'an indication that UE A is to be de-registered' } 
then { IMS_A sends a BYE to IMS_B 
containing Request_URI 

indicating the initial 200_OK_Contact_value sent by IMS_B 
and 
containing To_header 

indicating the initial 200_OK_To_vaiue sent by IMS_B and 
containing From_header 

indicating the initial INVITEFromvalue sent by IMS_A and 
containing Caii-IDheader 

indicating the initial INVITE_Call_ld_vaiue sent by IMS_A and 
containing CSeq_header 
indicating the initial INVITE_Cseq_value sent by IMS_A 
incremented by 1 and 
containing Route_header 

indicating "dialog specific routing information for UEB" and 
"further headers based on local policy or call release reason" 
and 

UE B receives BYE 
} 
} 
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The expected TB call flow is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

lUI 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






27 












^ 






User B is informed tliat call is in progress 


28 








^ 








BYE 


IMS_A S-CSCF releases the call towards the 
called user with BYE 


29 










^ 






BYE 


IMS B P-CSCF forwards BYE to UE B 


30 












^ 






User B is informed the call lias ended 


31 










^ 






200 OK 


UE B sends 200 OK for BYE 


32 








^ 








200 OK 


IIVIS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


33 






4- 










BYE 


IMS_A S-CSCF releases the call towards the calling 
user with BYE 


34 




^ 














User A is informed the call has ended 


35 






^ 










200 OK 


UE A sends 200 OK for BYE 
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4.5.2.3.8 S-CSCF initiated session release from terminating network 



Test description 


Identifier: 


ID IMS 0023 


Summary: 


S-CSCF-initiated release of established session from terminating network 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


IP IMS 5139 02 


TS 124 229 [1], clause 5.4.5.1.2, HI 


Use Case: 


UC_09 (CFW for terminating network) | 




Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 1 0Orel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UEA registered using user_1_priv@ims-a.net as per clause 4.2.3 

• UEB registered using user_1_priv@ims-b.net as per clause 4.2.3 

• UE A, UE B registered public identities are SIP URIs only 


L 






Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to "user 1 pub@ims-b.net" 
(CFW step 1) 


2 PR 


Verify that UEB rings (CFW step 8) 


3 PR 


Verify that ringback is present at UE A (CFW step 12) 


4 PR 


Answer the call at UE B (CFW step 1 9) 


5 PR 


Verify that voice can be exchanged in both directions (CFW step 27) 


6 TB 


Set UE B registration status to de-registered in IIWS B HSS 
(CFW step 28) 


7 TB 


Verify tliat call is ended at UE_A (CFW step 30) 


8P0 


Verify that call is ended at UE B (CFW step 34) 


9P0 


Verify that UE B is deregistered 




Conformance 
criteria: 


Check 




1 




TP_IMS_5139_02 in CFW step 28 (BYE): 
ensure that { 
when { IMS B receives 'an indication that UE B is no longer available'} 
then { IMS_B sends a BYE to IMS_A 
containing Request_URI 

indicating the initial INVITE_Contact_value sent by ll\/IS_A 
and 
containing To_header 

indicating the initial INVITE_From_value sent by IMS_A and 
containing From_header 

indicating the initial 200_OK_To_value sent by IMS_B and 
containing Call-IDheader 

indicating the initial INVITE_Call_ld_value sent by IMS_A and 
containing CSeq_header 
indicating the CSeq_value of the last request sent by IMS_B 
incremented by 1 and 
containing Route_header 

indicating "dialog specific routing information for UEA" and 
"further headers based on local policy or call release reason" 
and 

UE A receives BYE 
} 
} 
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The expected TB call flow is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

lUI 
S 
A 


1 
lUI 

s 

B 


U 

E 
B 


U 
s 
e 
r 
B 






27 












^ 






User B is informed that call is in progress 


28 








<- 








BYE 


IIVIS_B S-CSCF releases the call towards the 
calling user with BYE 


29 






<- 










BYE 


IMS A P-CSCF forwards BYE to UE B 


30 




^ 














User A is informed the call has ended 


31 






^ 










200 OK 


UE A sends 200 OK for BYE 


32 








^ 








200 OK 


IIVIS A S-CSCF forwards 200 OK response to 
IIVIS B S-CSCF 


33 










^ 






BYE 


IMS_B S-CSCF releases the call towards the called 
user with BYE 


34 












^ 






User B is informed the call has ended 


35 










^ 






200 OK 


UE B sends 200 OK for BYE 



4.5.3 Subsequent requests within dialog procedures 



4.5.3.1 Subsequent UPDATE target refresh request procedures 



Test description 



Identifier: 



TD IMS 0024 



Summary: 



Subsequent UPDATE target refresh requests and 200 OK response procedures 



Configuration: 



CF IVI02-SS1-MT2 



References 



Test purpose 



TP IIVIS 5048 02 



TP IMS 5058 02 



TP IMS 5106 02 



Specification reference 



TS 124 229 [1], clause 5.2.6.3, H 26 



TS 124 229 [1], clause 5.2.6.4, H 67 



TS 124 229 [1], clause 5.4.3.2, ^ 42 



Use Case: 



UC_06 (CFW for UPDATE) 



Pre-test 
conditions: 



Static configuration as per clause 4.3 

UE_A, UE_B support lOOrel, no SDP preconditions 

UE_A, UE_B have no filter criteria defined in HSS 

UE_A, UE_B IP bearers established as per clause 4.2.1 

UE_A registered using user_1_priv@ims-a.net as per clause 4.2.3 

UEB registered using user_1_priv@ims-b.net as per clause 4.2.3 

UE_A, UE_B registered public identities are SIP URIs only 

UEA, UEB support UPDATE method for call hold/resume 



Test sequence: 



Step 



1 PR 



2 PR 



3 PR 



4 PR 



5 PR 



6 TB 



7 TB 



8 TB 



9 TB 



10PO 



11 PO 



Initiate an IMS VoIP call on UE_A, 
(CFW step 1) 



addressed to "user_1_pub@ims-b.net" 



Verify that UE_B rings (CFW step 8) 



Verify that ringback is present at UE_A (CFW step 12) 



Answer the call at UE_B (CFW step 1 9) 



Verify that voice can be exchanged in both directions (CFW step 27) 



Place call on hold at UE_A (CFW step 28) 



Verify that voice can no longer be exchanged in both directions 
(CFW step 32) 



Resume call at UE_A (CFW step 36) 



Verify that voice can be exchanged in both directions (CFW step 44) 

Release call at UE_A (CFW step 45) 



Verify that call is released at UE B (CFW step 49 
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Test description 


Conformance 
criteria: 


Check 




1 


TP_IMS_5048_02 in CFW step 30 and 38 (UPDATE): 
ensure that { 
when { UE A sends UPDATE toUE B} 
then { IMS_B receives the UPDATE 

containing an additional Via_header 
containing ( P-CSCF_port_number 'where it awaits the 
responses to arrive' and 
(P-CSCF-FQDN address or 
P-CSCF-iP_address)) of IMS_A and 
containing an additional topmost Record-Route_header 
containing ( P-CSCF_port_number "where it awaits subsequent 
requests from the caiied party" and 
(P-CSCF-FQDN address or 
P-CSCF-IP_address)) of IMS_A 
and 

UE B receives UPDATE 
} 
} 






TP_IMS_5058_02 in CFW step 34 and 42 (200 0I<): 
ensure that { 
when { UEB sends a 2xx_response to UFA } 
then { IMS_A receives 2xx_response 

containing Record-Route_header 
containing the same P-CSCF_port_number of ll\/IS_B "as in the 

response to the previous initial request" and 
not containing a comp_parameter 
and 

UE A receives 2xx response 
} 
} 






TP_IMS_5106_02 in CFW step 30 and 38 (UPDATE): 
ensure that { 
when { UE_A sends subsequent UPDATE to UE_B} 
then { IMS_B receives the subsequent UPDATE 

containing a topmost Record-Route header 

containing the S-CSCF_SIP_URI of IMS_A and 
containing a P-Charging-Vector_header 

not containing a access-network-charging-info_parameter 
and 

not containing a P-Access-Networl<-lnfo_header 
and 

UE B receives the UPDATE} 
} 



The expected test body (TB) call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


U 
s 
e 
r 
B 






28 




-> 














User A put call on hold 


29 






^ 










UPDATE 


UE A sends UPDATE message indicating media 
stream inactive (Call Hold) 


30 








-^ 








UPDATE 


IMS A S-CSCF forwards UPDATE to IMS B 
S-CSCF 


31 










^ 






UPDATE 


IMS B P-CSCF forwards UPDATE to UE B 


32 












^ 






User B is informed that call on hold 


33 










<r 






200 OK 


UE_B responds to UPDATE with 200 OK 
indicating media stream inactive 


34 








<r 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


35 






<r 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 
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Step 


Direction 


IVIessage 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


1 

lUI 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






36 




^ 














User A resumes call 


37 






^ 










UPDATE 


UE A sends UPDATE message indicating media 
stream active (Call Resume) 


38 








-» 








UPDATE 


IMS A S-CSCF forwards UPDATE to IMS B 
S-CSCF 


39 










^ 






UPDATE 


IMS BP-CSCF forwards UPDATE to UE B 


40 












^ 






User B is informed the call is resumed 


41 










<- 






200 OK 


UE_B responds to UPDATE with 200 OK 
indicating media stream active 


42 








<- 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


43 






<- 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


44 




^ 














User A is informed that call is resumed 



4.5.3.2 Subsequent PRACK request procedures 



Test description | 


Identifier: 


TD IMS 0025 


Summary: 


Subsequent PRACK requests and 200 OK response procedures 


Configuration: 


OF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5107 01 


TS 124 229 [1], clause 5.4.3.2, % 49 


TP IMS 5121 02 


TS 124 229 [1], clause 5.4.3.3, H 60 


Use Case: 


UC 01 1 


^^ 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 1 0Orel, no SDR preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IR bearers established as per clause 4.2.1 

• UEA registered using user_1_priv@ims-a.net as per clause 4.2.3 

• UEB registered using user_1_priv@ims-b.net as per clause 4.2.3 

• UE A, UE B registered public identities are SIR URIs only 




Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to "user 1 pub@ims-b.net" 
(CFWstepI) 


2 PR 


Verify that UEB rings (CFW step 8) 


3 PR 


Verify that ringback is present at UE A (CFW step 12) 


4 TB 


Answer the call at UE_B (CFW step 19) 


5P0 


Verify that voice can be exchanged in both directions (CFW step 27) 


6P0 


Release call at UE A (CFW step 28) 


7P0 


Verify that call is released at UE B (CFW step 32) 


L 1 


Conformance 
criteria: 


Check 


1 


1 


TP_IMS_5107_01 in CFW step 14 (PRACK): 
ensure that { 
when { UE_A sends PRACK to UE_B } 
then { IMS_B receives the PRACK 

(containing a P-Charging-Vector_header 

not containing a access-networl<-charging-info_parameter 
or 

not containing a P-Charging-Vectorheader ) 
and 

not containing a P-Access-Networl<-lnfo_header 
and 

UE B receives the PRACK} 
} 
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Test description 



TP_IMS_5121_02 in CFW step 17 (200 OK): 
ensure that { 
when { DEB sends 2xx_response to UEA } 
then { IMS_A receives the 2xx_response 

containing a P-Charging-Vector_header 

not containing a access-networl<-charging-info_parameter 
and 

not containing a P-Access-Networl<-lnfo_header 
and 

UEA receives the 2xx_response } 
I 



The expected test body (TB) call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


U 
s 
e 
r 
B 






13 






^ 










PRACK 


UE_A acknowledges the receipt of 180 response 
by sending PRACK 


14 








^ 








PRACK 


IMS A S-CSCF forwards PRACK to IMS B 
S-CSCF 


15 










^ 






PRACK 


IMS BP-CSCF forwards PRACK to UE B 


16 










<r 






200 OK 


UE_B responds PRACK with 200 OK 


17 








^ 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


18 






^ 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 
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4.5.3.3 Subsequent BYE request procedures 



Test description 


Identifier: 


ID IMS 0026 


Summary: 


Subsequent BYE requests and 200 OK response procedures 


Configuration: 


OF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


IP IMS 5107 02 


TS 124 229 [1], clause 5.4.3.2, H 49 


IP IMS 5121 02 


TS 124 229 [1], clause 5.4.3.3, H 60 


Use Case: 


UC 01 1 


^^ ■^^^^■— 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 1 0Orel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UEA registered using user_1_priv@ims-a.net as per clause 4.2.3 

• UEB registered using user_1_priv@ims-b.net as per clause 4.2.3 

• UE A, UE B registered public identities are SIP URIs only 


1 "^ 




Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to "user 1 pub@ims-b.net" 
(CFWstepI) 


2 PR 


Verify that UEB rings (CFW step 8) 


3 PR 


Verify that ringback is present at UE A (CFW step 12) 


4 PR 


Answer the call at UE B (CFW step 1 9) 


5 PR 


Verify that voice can be exchanged in both directions (CFW step 27) 


6 TB 


Release call at UE_A (CFW step 28) 


7 TB 


Verify that call is released at UE_B (CFW step 32) 


^^^v ^^^ m 


Conformance 
criteria: 


Clieck 




1 


TP_IMS_5107_02 in CFW step 30 (BYE): 
ensure that { 
when { UE_A sends BYE to UE_B } 
then { IMS_B receives the BYE 

(containing a P-Charging-Vector_heacler 

not containing a access-networl<-charging-info_parameter 
or 

not containing a P-Charging-Vector_heacler ) 
and 

not containing a P-Access-Networl<-lnfo__header 
and 

UE B receives the BYE} 
} 


2 


TP_IMS_5121_02 in CFW step 34 (200 OK): 
ensure that { 
when { UEB sends 2xx_response to UEA } 
then { iMS_A receives the 2xx_response 

containing a P-Charging-Vector_header 

not containing a access-networl<-charging-info_parameter 
and 

not containing a P-Access-Networl<-info_header 
and 

UE A receives the 2xx response } 
} 
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The expected test body (TB) call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






29 






^ 










BYE 


UE A releases the call with BYE 


30 








-» 








BYE 


IMS A S-CSCF forwards BYE to IMS B 
S-CSCF 


31 










^ 






BYE 


IMS BP-CSCF forwards BYE to UE B 


32 












^ 






User B is informed that call has ended 


33 










<- 






200 OK 


UE B sends 200 OK for BYE 


34 








<- 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


35 






<- 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 



4.5.3.4 Subsequent INVITE target refresh request procedures 



Test description 



Identifier: 



TD IMS 0027 



Summary: 



Subsequent INVITE target refresh requests and 200 OK response procedures 



Configuration: 



OF IV102-SS1-MT2 



References 



Test purpose 



TP IIVIS 5048 01 



TP IMS 5058 02 



TP IMS 5106 01 



Specification reference 



TS 124 229 [1], clause 5.2.6.3, H 26 



TS 124 229 [1], clause 5.2.6.4, H 67 



TS 124 229 [1], clause 5.4.3.2, H 42 



Use Case: 



Pre-test 
conditions: 



UC_06 (CFW for relNVITE) 



Static configuration as per clause 4.3 

UE_A, UE_B support lOOrel, no SDP preconditions 

UE_A, UE_B have no filter criteria defined in HSS 

UE_A, UE_B IP bearers established as per clause 4.2.1 

UE_A registered using user_1_priv@ims-a.net as per clause 4.2.3 

UE_B registered using user_1_priv@ims-b.net as per clause 4.2.3 

UE_A, UE_B registered public identities are SIP URIs only 

UEA, UEB support relNVITE method for call hold/resume 



Test sequence: 



Step 



1 PR 



2 PR 



3 PR 



4 PR 



5 PR 



6 TB 



7 TB 



STB 



9 TB 



10PO 



11 PO 



Initiate an IMS VoIP call on UE_A, addressed to "user_1_pub@ims-b.net" 
(CFW step 1) 



Verify that UE_B rings (CFW step 8) 



Verify that ringback is present at UE_A (CFW step 12) 



Answer the call at UE_B (CFW step 1 9) 



Verify that voice can be exchanged in both directions (CFW step 27) 



Place call on hold at UE_A (CFW step 29) 



Verify that voice can no longer be exchanged in both directions 
(CFW step 35) 



Resume call at UE_A (CFW step 42) 



Verify that voice can be exchanged in both directions (CFW step 53) 

Release call at UE_A (CFW step 57) 



Verify that call is released at UE B (CFW step 61 
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Test description 


Conformance 
criteria: 


Check 




1 


TP_IMS_5048_01 in CFW step 31 and 45 (INVITE): 
ensure that { 
when { UEA sends subsequent INVITEs to DEB } 
then { IMS_B receives the subsequent INVITEs 
containing an additional Via_header 
containing ( P-CSCF_port_number 'where it awaits the 
responses to arrive' and 
(P-CSCF-FQDN address or 
P-CSCF-IP_address)) of IMS_A and 
containing an additional Record-Route_header 
containing ( P-CSCF_port_number "where it awaits subsequent 
requests from the called party" and 
(P-CSCF-FQDN address or 
P-CSCF-IP_address)) of IMS_A 
and 

UE B receives INVITEs 
} 
} 




2 


TP_IMS_5058_02 in CFW step 37 and 51 (200 Ok): 
ensure that { 
when { UEB sends 2xx_responses for subsequent INVITEs to UEA } 
then { IMS_A receives 2xx_responses 

containing Record-Route_header 
containing the same P-CSCF_port_number of IMS_B "as in the 

response to the previous initial request" and 
not containing a comp_parameter 
and 

UE A receives 2xx responses 
} 
} 




3 


TP_IMS_5106_01 in CFW step 31 and 45 (INVITE): 
ensure that { 
when { UEA sends subsequent INVITEs to UEB } 
then { IMS_B receives the subsequent INVITEs 

containing a topmost Record-Route header 

containing the S-CSCF_SIP_URI of IMS_A and 
containing a P-Charging-Vector_header 

not containing a access-network-charging-info_parameter 
and 

not containing a P-Access-Network-lnfo_header 
and 

UE B receives the INVITEs } 
} 



The expected test body (TB) call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






28 




-> 














User A puts call on hold 


29 






^ 










INVITE 


UE A sends relNVITE message indicating media 
stream inactive (Call Hold) 


30 






«- 










100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


31 








^ 








INVITE 


IMS A S-CSCF forwards INVITE to IMS B 
S-CSCF 


32 








^ 








100 Trying 


IMS_B S-CSCF responds with a 100 Trying 
provisional response 


33 










^ 






INVITE 


IMS B P-CSCF forwards INVITE to UE B 


34 










^ 






100 Trying 


UE_B responds with a 100 Trying provisional 
response 


35 


















User B is informed that call on hold 
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Step 


Direction 


IVIessage 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


U 
s 
e 
r 
B 






36 










<r 






200 OK 


UE_B responds to INVITE with 200 OK 
indicating media stream inactive 


37 








<- 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


38 






<- 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


39 






-^ 










ACK 


UE A acl<nowledges tlie receipt of 200 OK for 
INVITE 


40 








■^ 








ACK 


IMS A S-CSCF forwards ACK to IMS B 
S-CSCF 


41 










■^ 






ACK 


IMS B P-CSCF forwards ACK to UE B 


42 


















User A resumes call 


43 






-^ 










INVITE 


UE_A sends relNVITE message indicating media 
stream active (Call Resume) 


44 






^ 










100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


45 








^ 








INVITE 


IMS A S-CSCF forwards INVITE to IMS B 
S-CSCF 


46 








^ 








100 Trying 


IMS_B S-CSCF responds with a 100 Trying 
provisional response 


47 










■^ 






INVITE 


IMS B P-CSCF forwards INVITE to UE B 


48 










<- 






100 Trying 


UE_B responds with a 100 Trying provisional 
response 


49 


















User B is informed the call is resumed 


50 










<- 






200 OK 


UE_B responds to UPDATE with 200 OK 
indicating media stream active 


51 








<r 








200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


52 






<- 










200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


53 


















User A is informed that call is resumed 
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4.5.3.5 Subsequent CANCEL request procedures 



Test description 


Identifier: 


ID IMS 0028 


Summary: 


Subsequent CANCEL request procedures 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


IP IMS 5107 04 


TS 124 229 [1], clause 5.4.3.2, H 49 


IP IMS 5121 02 


TS 124 229 [1], clause 5.4.3.3, H 60 


Use Case: 


UC 04 1 




Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UEA support lOOrel, no SDP preconditions 

• UE_A have no filter criteria defined in HSS 

• UEA IP bearers established as per clause 4.2.1 

• UEA registered using user_1_priv@ims-a.net as per clause 4.2.3 

• UE_B registered using user_1_priv@ims-b.net as per clause 4.2.3 

• UE A registered public identities are SIP URIs only 


1 ^^^ 




Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to "user 1 pub@ims-b.net" 
(GFWstepI) 


2 PR 


Verify that UE B rings (GFW step 8) 


3 PR 


Verify that ringback is present at UE A (GFW step 12) 


4 TB 


End call at UE A (CFW step 19) 


5P0 


Verify that call is ended at UE_B (CFW step 26) 


Conformance 
criteria: 


Check 


' 


1 


TP_IMS_5107_04 in CFW step 22 (CANCEL): 
ensure that { 
when { UE_A sends CANCEL to UE_B } 
then { IMS_B receives the CANCEL 

(containing a P-Charging-Vector_header 
not containing a access-networi<-charging-info_parameter 
or 

not containing a P-Charging-Vector_header) and 
not containing a P-Access-Networl<-lnfo_header 
and 

UE B receives the CANCEL } 
} 


2 


TP_IMS_5121_02 in CFW step 23 (200 OK): 
ensure that { 
when { UEB sends 2xx_response to UEA } 
then { IMS_A receives the 2xx_response 

(containing a P-Charging-Vector_header 
not containing a access-networl<-charging-info_parameter 
or 

not containing a P-Charging-Vector_header) and 
not containing a P-Access-Networl<-lnfo_header 
and 

UE A receives the 2xx response } 
} 
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The expected test body call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






19 




-» 














User A cancel ringing 


20 






^ 










CANCEL 


UE A sends CANCEL to abort call 


21 






^ 










200 OK 


IMS_A P-CSCF responds with a 200 OK 
response 


22 








^ 








CANCEL 


IMS A S-CSCF sends CANCEL to IMS B S- 
CSCF 


23 








^ 








200 OK 


IMS_B S-CSCF responds with a 200 OK 
response 


24 










-^ 






CANCEL 


IMS B P-CSCF sends CANCEL to UE B 


25 










^ 






200 OK 


UE_B responds with a 200 OK response 


26 












^ 






User B informed that call is aborted 


27 










^ 






487 Request Terminated 


UE_B confirms cancellation of the INVITE request 
with a 487 Request Terminated error response 


28 










^ 






ACK 


IMS B P-CSCF responds with an ACK to UE B 


29 








^ 








487 Request Terminated 


IMS_B S-CSCF sends a 487 Request Terminated 
error response to IIVIS A S-CSCF 


30 








-> 








ACK 


IMS A S-CSCF responds with an ACK 


31 






^ 










487 Request Terminated 


IMS_B P-CSCF sends a 487 Request Terminated 
error response to UE A 


32 






^ 










ACK 


UE A responds with an ACK 
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